I have a Rust / GTK desktop application that uses OpenGl. Since upgrading to Fedora 40 this now crashes when running in the Gnome Desktop under Wayland. The error, which is quite spurious is: error: vertex shader lacks `main'\n\0 The shader program is being created in a simple OpenGL call let vert_shader = Shader::from_vert_source( &CString::new(include_str!("program.vert")).unwrap() ).unwrap(); let frag_shader = Shader::from_frag_source( &CString::new(include_str!("program.frag")).unwrap() ).unwrap(); let shader_program = Program::from_shaders( &[vert_shader, frag_shader] ).unwrap(); The 2 shaders are very trivial: #version 330 in vec3 vColor; out vec4 f_color; void main() { f_color = vec4(vColor, 1.0); } and #version 330 layout (location = 0) in vec3 Position; out vec3 vColor; uniform mat4 matrix; uniform vec3 color; void main() { gl_Position = matrix * vec4(Position, 1.0); vColor = color; } Running the program either in a Gnome X11 session or using GDK_BACKEND=x11 ./kelpie_rust_planner causes no errors and the program executes and displays as expected. I witnessed no problems under Fedora 39. Reproducible: Always Steps to Reproduce: 1. Download the Kelpie Flight Planner app from https://github.com/shartrec/kelpie-flight-planner 2. Open the application in a Gnome/Wayland session 3. Click on the Map tab in the right hand pane of the main window. Actual Results: Applicartion crashes with: error: vertex shader lacks `main'\n\0 Expected Results: Application does not crash trevor ~ glxinfo | grep "OpenGL" OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 630 (KBL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.5 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.5 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions:
Hi @trevor Doesn't it print more information on your side? Here it prints: ``` called `Result::unwrap()` on an `Err` value: "0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES\n\0" note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` And for what I see in your glxinfo command: "OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20" Targeting a lower version should fix your issue. I'm not sure why it works in Fedora 39 thought. I guess it is due a change in mesa. It might be worth to report it upstream, even though the version of mesa in Fedora 40 is doing the right think and it is failing because your shaders have "#version 330".
Wayland is just a protocol specification in XML and the low-level C library that deals with the protocol. This issue here is a not a bug with the protocol itself, but rather in the libraries, possibly Mesa.
Hi jexposit Thanks for the feedback. I have tried chasing down the version path but had no success. I have tried changing the shaders to "#version 310" but get the more confusing result that GLSL 3.20 is not supported. I really believe that version 4.60 is actually supported, which confuses me more, but I am no expert here. This is the first time I have used shaders and all that complex GTK canvas / OpenGL stuff. trevor ~ KelpieRustPlanner target debug glxinfo | grep OpenGL ST 2 main OpenGL vendor string: Intel OpenGL renderer string: Mesa Intel(R) HD Graphics 630 (KBL GT2) OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.0.5 OpenGL core profile shading language version string: 4.60 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.5 OpenGL shading language version string: 4.60 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.0.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 OpenGL ES profile extensions: trevor ~ KelpieRustPlanner target debug ./kelpie_rust_planner ST 2 main thread 'main' panicked at src/window/render_gl.rs:199:11: called `Result::unwrap()` on an `Err` value: "0:1(10): error: GLSL 3.20 is not supported. Supported versions are: 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES\n\0" note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
Further investigation shows very different versions supported when using X11. After changing the shader version to 3.20. I get the following when not using X11 and then using X11 trevor ~ KelpieRustPlanner target debug ./kelpie_rust_planner 101 ST 2 main thread 'main' panicked at src/window/render_gl.rs:199:11: called `Result::unwrap()` on an `Err` value: "0:1(10): error: GLSL 3.20 is not supported. Supported versions are: 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES\n\0" note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace trevor ~ KelpieRustPlanner target debug GDK_BACKEND=x11 ./kelpie_rust_planner 101 ST 2 main thread 'main' panicked at src/window/render_gl.rs:199:11: called `Result::unwrap()` on an `Err` value: "0:1(10): error: GLSL 3.20 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.40, 1.50, 3.30, 4.00, 4.10, 4.20, 4.30, 4.40, 4.50, 4.60, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES\n\0" note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Partially resolved. I can get my particular program to work by changing the shader version. In Fedora 40 under Wayland (I realise this is not actually a Wayland issue) it appears only the "es" shader language versions are supported as evidenced by: "Supported versions are: 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES\n\0". Notice the ES appended to each version. I changed my shaders to use "#version 320 es". This is however is a different shader language and further adjustments are required. e.g. Calls to gl::PointSize(point_size); don't work. I feel that it is not intentional, in Fedora 40, that the way Mesa (or whatever it is - not my area of expertise here) is initialissed when the desktop is running under Wayland that the OpenGL environment should be so different to that when using Xorg. I don't think the issue is resolved overall, because other applications must surely run into this problem.
Further reading leads me to this definition at https://www.khronos.org/opengl/wiki/OpenGL_ES ``` OpenGL ES is an “embeddable subset” of OpenGL. It slims down the rather large OpenGL API to the bare essentials, so that it can be implemented on devices with simpler, cheaper hardware, and above all, low enough power requirements to run on batteries. For example, it is available as standard on smartphones running both Apple’s IOS and Google’s Android operating system. ``` I don't think the Fedora 40 desktop should be restricted to OpenGL ES.
Hi @trevor I tested with a minimal reproducer (plain OpenGL): https://github.com/JoseExposito/LearnOpenGL/blob/main/02-hello-triangle/main.c $ git clone https://github.com/JoseExposito/LearnOpenGL.git $ cd LearnOpenGL/02-hello-triangle $ meson setup builddir $ ninja -C builddir $ ./builddir/hello-triangle And the shader works as expected ("#version 330 core"). With another reproducer, this time using GTK 3: https://github.com/kion-dgl/DashGL-GTK-Brickout-Tutorial/tree/master/02_Draw_a_Triangle $ git clone https://github.com/kion-dgl/DashGL-GTK-Brickout-Tutorial.git $ cd DashGL-GTK-Brickout-Tutorial/02_Draw_a_Triangle # Optionally, you can change the shader version to 330 here # https://github.com/kion-dgl/DashGL-GTK-Brickout-Tutorial/blob/master/02_Draw_a_Triangle/main.c#L97-L104 $ make $ ./a.out I found no issues. I think this test discards mesa as the component causing the issue. I couldn't find a GTK 4 example. It would be nice if you could create a minimal reproducer for the issue using the same libraries used by Kelpie flight planner to figure out if the issue is caused by a library (GTK4, the Rust bindings, etc) or if it is a problem in your app.
Hi @jexposit, I have been able to test with both the minimal reproducers you suggested, and they worked correctly for me. I have cut my Rust/GTK4 program down to the bare minimum and still get the error, so am continuing to dig deeper. Thanks for your help so far. I'll continuing looking into this mystery and will update here with my findings. Trevor
Adding some debug lines to print out version/vendor info I found: * Under Wayland ``` GL_Version "OpenGL ES 3.2 Mesa 24.0.5" GL_Vendor "Intel" GL_Renderer "Mesa Intel(R) HD Graphics 630 (KBL GT2)" ``` * Under X11 ``` GL_Version "4.6 (Core Profile) Mesa 24.0.5" GL_Vendor "Intel" GL_Renderer "Mesa Intel(R) HD Graphics 630 (KBL GT2)" ``` I don't understand why this should happen but.... Somehow under GDK4 I need to find a way to request the core profile. (Well for my case I can work around this, but for others it would be good to document)
Hi @ajax Alex, believe I can now close this bug report. This is apparently the result of an intentional change in GTK4. I had the follwing exchange on Gnome Discourse channel (https://discourse.gnome.org/t/how-to-request-the-opengl-core-profile/20907/2) Thanks @jexposit for helping me get to the bottom of this. Trevor