PrusaSlicer requires OpenGL 3.2 capable graphics driver to run correctly…

[stixpjr]

Description of the bug

I've been maintaining a NetBSD pkgsrc port of Prusaslicer, which has been running just fine on my amd64 system up to release 2.7.1. Likely since commit https://github.com/prusa3d/PrusaSlicer/commit/1832c833a1747e5ff6ba5025d634182313737db7 I get the above PrusaSlicer requires OpenGL 3.2 capable graphics driver to run correctly… check, and no fallback. I've modified my local source to allow OpenGL 3.0. With this, I get a complaint Unable to load the following shaders: dashed_thick_lines, but otherwise it appears to run fine. Yes, this workstation is running a fairly old Sandybridge CPU.

Prusaslicer reports:

OpenGL installation
GL version: 3.0.0 (3.0 Mesa 19.1.17)
Profile: Core
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Sandybridge Desktop 
GLSL version: 1.30.0
Textures compression: Enabled

glxinfo reports, in part:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Sandybridge Desktop  (0x102)
    Version: 19.1.17
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.1.17
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

I don't pretend to understand OpenGL well, but my core profile appears to be 3.3, while the compatibility profile is 3.0. Should this work, or at least fall back to a software renderer?

Project file & How to reproduce

N/A

Checklist of files included above

• [ ] Project file
• [ ] Screenshot

Version of PrusaSlicer

2.7.2-rc1

Operating system

NetBSD 10.0_RC4 amd64

Printer model

Prusa Mini

[fredvj]

Similar issue here. Older hardware (my trusty old Dell Notebook used for slicing) with no OpenGL 3.2 support. No plater view after software complains. Prusa Slicer 2.6.1 just recommended to update to the latest and "greatest".

Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel (0x8086) Device: Mesa Mobile Intel® GM45 Express Chipset (CTG) (0x2a42) Version: 23.2.1 Accelerated: yes Video memory: 1536MB Unified memory: yes Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: Intel OpenGL renderer string: Mesa Mobile Intel® GM45 Express Chipset (CTG) OpenGL version string: 2.1 Mesa 23.2.1-1ubuntu3.1~22.04.2 OpenGL shading language version string: 1.20

[gllmAR]

Similar issue also on raspberry pi (arm64 debian 12)

2.7.2 PrusaSlicer requires OpenGL 3.2 capable graphics driver to run correctly 2.7.1 running fine, no problem

glxinfo report :

 Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Broadcom (0x14e4)
    Device: V3D 7.1 (0xffffffff)
    Version: 23.2.1
    Accelerated: yes
    Video memory: 8048MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.1
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.1
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 7.1

[stixpjr]

fwiw, I'm currently running with the following workaround:

--- src/slic3r/GUI/OpenGLManager.cpp.orig       2024-02-23 10:58:40.000000000 +0000
+++ src/slic3r/GUI/OpenGLManager.cpp
@@ -373,7 +373,7 @@ bool OpenGLManager::init_gl()
 #if ENABLE_OPENGL_ES
         bool valid_version = s_gl_info.is_version_greater_or_equal_to(2, 0);
 #elif ENABLE_GL_CORE_PROFILE
-        const bool valid_version = s_gl_info.is_version_greater_or_equal_to(3, 2);
+        const bool valid_version = s_gl_info.is_version_greater_or_equal_to(3, 0);
 #else
         bool valid_version = s_gl_info.is_version_greater_or_equal_to(2, 0);
 #endif // ENABLE_OPENGL_ES

[PaulKGrimes]

For those trying to run 2.7.2 on a Raspberry Pi (tested on a 5), running the AppImage with MESA_GL_VERSION_OVERRIDE=3.2 PrusaSlicer.AppImage at least gets PrusaSlicer to run and display a bed.

However, it seems that PrusaSlicer will no longer be compatible with Raspberry Pis if OpenGL 3.2 is used.

[nvtkaszpir]

ouch, this effectively now affects massive amount of hardware

[Botspot]

This broke PrusaSlicer on Raspberry Pi. https://github.com/Botspot/pi-apps/issues/2560

[Botspot]

Pinging the two users who were involved in this problematic commit: @enricoturri1966 @lukasmatena

[theofficialgman]

Description of the bug

I've been maintaining a NetBSD pkgsrc port of Prusaslicer, which has been running just fine on my amd64 system up to release 2.7.1. Likely since commit 1832c83 I get the above PrusaSlicer requires OpenGL 3.2 capable graphics driver to run correctly… check, and no fallback. I've modified my local source to allow OpenGL 3.0. With this, I get a complaint Unable to load the following shaders: dashed_thick_lines, but otherwise it appears to run fine. Yes, this workstation is running a fairly old Sandybridge CPU.

Prusaslicer reports:

OpenGL installation
GL version: 3.0.0 (3.0 Mesa 19.1.17)
Profile: Core
Vendor: Intel Open Source Technology Center
Renderer: Mesa DRI Intel(R) Sandybridge Desktop 
GLSL version: 1.30.0
Textures compression: Enabled

glxinfo reports, in part:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Sandybridge Desktop  (0x102)
    Version: 19.1.17
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Desktop 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.1.17
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

I don't pretend to understand OpenGL well, but my core profile appears to be 3.3, while the compatibility profile is 3.0. Should this work, or at least fall back to a software renderer?

your issue appears to be because of a false assumption by the Prusaslicer developers

 // reset version as compatibility profile always take the highest version
        // supported by the graphic card

as seen by the output from glxinfo on your card, that statement is false. the compatibility profile is lower than the maximum supported version by the card

according to OpenGL docs, compatibility profile is not even required and it certainly isn't required to equal the max core profile version https://www.khronos.org/opengl/wiki/OpenGL_Context

[theofficialgman]

or at least fall back to a software renderer?

a bundled software renderer is only provided on Windows official builds of Pruslicer https://github.com/prusa3d/PrusaSlicer/blob/4f035bceb75661719b23d13fceddc62ccab6c54e/src/slic3r/GUI/OpenGLManager.cpp#L396-L399 this is because they build the MESA for windows and include the software llvmpipe renderer

they could definitely add a codepath to use a distro available llvmpipe MESA software renderer on linux if they wanted to do so and OpenGL 3.2 isn't available but that is not implemented

[PaulKGrimes]

Better would be to stay with OpenGL 3.1 or lower compatible features, to allow hardware acceleration on RPis and other typical maker computers.

[3dpr-foss]

Even the newest Raspberry Pi 5 only supports up to OpenGL 3.1 - Removing compatibility from the RPI is really disappointing. Especially bad for Education and people who can't a afford a foll blown computer!

[jjgcc]

Same here, I'm disappointed they're dropping support for old devices in this way...

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Mesa Mobile Intel® GM45 Express Chipset (CTG) (0x2a42)
    Version: 22.3.6
    Accelerated: yes
    Video memory: 1536MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Mobile Intel® GM45 Express Chipset (CTG)
OpenGL version string: 2.1 Mesa 22.3.6
OpenGL shading language version string: 1.20

[brandonridge]

For what its worth I found that if you enable OpenGLES and then build it from source it works fine, at least on my Raspberry Pi. Seems like the minimum version of the embedded version of OpenGL is still 2.0.

--- a/src/libslic3r/Technologies.hpp
+++ b/src/libslic3r/Technologies.hpp
@@ -52,7 +52,7 @@
 #define ENABLE_SMOOTH_NORMALS 0

 // Enable OpenGL ES
-#define ENABLE_OPENGL_ES 0
+#define ENABLE_OPENGL_ES 1
 // Enable OpenGL core profile context (tested against Mesa 20.1.8 on Windows)
 #define ENABLE_GL_CORE_PROFILE (1 && !ENABLE_OPENGL_ES)

[stixpjr]

I now note with 2.8.0alpha5, my workaround no longer works: the model is not displayed (just the baseplate), and I get a new error: LibVGCode requires an OpenGL context based on OpenGL 3.2 or higher.

That is… unfortunate. I guess I'll either have to hack around that, or have another attempt at the OpenGLES route.

[Botspot]

Hopefully someone can maintain a fork that keeps the rendering bits at the OpenGL 3.1 level, but pulls in other upstream changes.

[theofficialgman]

I now note with 2.8.0alpha5, my workaround no longer works: the model is not displayed (just the baseplate), and I get a new error: LibVGCode requires an OpenGL context based on OpenGL 3.2 or higher.

That is… unfortunate. I guess I'll either have to hack around that, or have another attempt at the OpenGLES route.

potential relevant changes to GLES pipeline https://github.com/prusa3d/PrusaSlicer/commit/1112fca6888b70617b1c3f209d478847e40d1439

[brandonridge]

I successfully have 2.8.0alpha5 working on my Raspberry Pi using OpenGLES. They moved the flag to building to use OpenGLES to a CMake flag. You need to add -DSLIC3R_OPENGL_ES=1 as a CMake flag when building.

I also had to make the following 2 changes to the source code along with the changes posted on this pull request https://github.com/prusa3d/PrusaSlicer/pull/12855/commits/59e8ca9ee512a6ca0620f40e7d3c7711e977163c

diff --git a/src/libvgcode/glad/include/glad/gles2.h b/src/libvgcode/glad/include/glad/gles2.h
index 2983e1df5..5691317c1 100644
--- a/src/libvgcode/glad/include/glad/gles2.h
+++ b/src/libvgcode/glad/include/glad/gles2.h
@@ -87,6 +87,10 @@ extern "C" {
   #endif
 #endif

+#ifndef GLAD_GLES2_USE_SYSTEM_EGL
+  #define GLAD_GLES2_USE_SYSTEM_EGL 1
+#endif
+
 #ifndef GLAD_PLATFORM_UWP
   #if defined(_MSC_VER) && !defined(GLAD_INTERNAL_HAVE_WINAPIFAMILY)
     #ifdef __has_include
diff --git a/src/slic3r/GUI/Gizmos/GLGizmoMeasure.cpp b/src/slic3r/GUI/Gizmos/GLGizmoMeasure.cpp
index 2e60f16ed..c26c94a82 100644
--- a/src/slic3r/GUI/Gizmos/GLGizmoMeasure.cpp
+++ b/src/slic3r/GUI/Gizmos/GLGizmoMeasure.cpp
@@ -1561,7 +1561,9 @@ void GLGizmoMeasure::render_dimensioning()
         const Vec3d label_position_world = Geometry::translation_transform(center) * (draw_radius * (Eigen::Quaternion<double>(Eigen::AngleAxisd(step * 0.5 * double(resolution), normal)) * e1_unit));

         // label screen coordinates
+#if !SLIC3R_OPENGL_ES
         const std::array<int, 4>& viewport = camera.get_viewport();
+#endif
         const Vec2d label_position_ss = TransformHelper::world_to_ss(label_position_world,
             camera.get_projection_matrix().matrix() * camera.get_view_matrix().matrix(), viewport);

Hopefully this will help others.

[stixpjr]

I've found I can successfully build with SLIC3R_OPENGL_ES=1, ENABLE_OPENGL_ES=1, GLAD_GLES2_USE_SYSTEM_EGL=1 and a mix of the above patches, but starting prusaslicer I get "Couldn't create OpenGL context" from wxGLContext::wxGLContext. Trying some more hacks - I'm lucky that my card supports core profile version 3.3, so, based on the above comments, it should work with OpenGL - if I can get it to ignore the compatibility profile.

That doesn't help the RPI users.

[stixpjr]

After a little stuffing around, I've found that removing ForwardCompatible() from the attrs, I can now use core profile version 3.3, with no errors whatsoever. Changes checked into pkgsrc wip. Specifically, this patch - removing ForwardCompatible() - the other changes shouldn't be required.