GNOME Bugzilla – Bug 756306
shader compilation fails with fglrx
Last modified: 2021-07-05 13:46:33 UTC
After using the patch from https://bugzilla.gnome.org/show_bug.cgi?id=741581#c20 to get past the sad computer screen, I only get a black screen with a cursor. From the journal: ERROR: error(#271) Explicit version number 120 not supported by GL3 forward compatible context catalyst version is 15.9 on linux-lts 4.1.10
It seems this bug is related to cogl. Violo, who maintains Catalyst packages for Arch Linux, has made a patch that simply bumps the shader's version number to 150, allowing it to compile, and efectively solving the problem. Patch : http://mirror.rts-informatique.fr/archlinux-catalyst/tarball/gnome318-problems/cogl-1.22.0-2.src.tar.gz Arch forum thread : https://bbs.archlinux.org/viewtopic.php?id=57084&p=287
Yes, this is a cogl bug. The shell should never use GL3.2, we use some GLSL shaders and we need the compatibility syntax, so we should only ask for 3.0 non-forward-compatible.
Created attachment 314263 [details] [review] Catalyst fix for glsl Vi0L0 found a solution which fixes Catalyst, but his solution broke it for everybody else. So I took the chance and created a working patch for this. After series of tests we found now the proper solution. We have tested it on Nvidia, Catalyst and other graphic drivers like Intel to confirm it working. Further information and patches can been found here: https://github.com/manjaro/packages-extra/tree/master/cogl
Review of attachment 314263 [details] [review]: Thanks for your patch. Could you please, for the next iteration, attach a patch generated via `git format-patch` or using git-bz? It would make review and commit a lot easier — and maintain attribution. ::: 122/cogl/driver/gl/gl/cogl-driver-gl.c @@ +49,3 @@ +static int +output_get_fglrx_kernel_module_loaded() Apart from this function not conforming to the Cogl coding style, the main issue is that Cogl already has a lot of code to deal with GPU/driver detection. @@ +61,3 @@ + char line[256]; + + */ This whole function should really be replaced by a driver quirk check using CoglGpuInfo. Poking into /proc/modules is definitely not a good solution.
(In reply to Giovanni Campagna from comment #2) > Yes, this is a cogl bug. > > The shell should never use GL3.2, we use some GLSL shaders and we need the > compatibility syntax, so we should only ask for 3.0 non-forward-compatible. No, this is a shell bug. The shell should use different shaders when running against core 3.2 profiles and legacy ones. Mesa and nVidia are apparently a lot more forgiving than the AMD driver when it comes to version selection, but the Shell should stop behaving like OpenGL >3.2 does not exist.
Created attachment 314455 [details] [review] gl: Add a quirk for the GLSL version to use on AMD The AMD Catalyst (fglrx) driver on Linux is far less forgiving than the Mesa and NVidia ones, and when presented with using GLSL version 1.20 on a forward-compatible core GL profile, it will bomb out. We can use a simple driver quirk, and bump up the required version for GLSL to 1.50 when using GL ≥ 3.2.
The patch in attachment 314455 [details] [review] implements the driver quirk I mentioned in comment #4. Since I don't have an ATi/AMD card, it would be great if somebody tested it. It would also be helpful to improve the detection of ATI/AMD GPUs if somebody attached the output of glxinfo/fglrxinfo to this bug.
Created attachment 314462 [details] [review] Use better vendor strings from ATi/AMD Improve the detection of ATi/AMD GPUs, especially latter ones.
I had to remove "COGL_CHECK_GL_VERSION (gl_major, gl_minor, 3, 2)" check from your patch, Emmanuele, to make it work on my Radeon 290X @ Arch 86_64
Created attachment 314558 [details] [review] modified Emmanuele's patch
(In reply to Vi0L0 from comment #9) > I had to remove "COGL_CHECK_GL_VERSION (gl_major, gl_minor, 3, 2)" check > from your patch, Emmanuele, to make it work on my Radeon 290X @ Arch 86_64 That's interesting. Which version of OpenGL does fglrxinfo report on your system? GLSL 1.50 is meant to be used for OpenGL 3.2 or later.
OpenGL version string: 4.5.13399 Compatibility Profile Context 14.201.1006.1002
(In reply to Vi0L0 from comment #12) > OpenGL version string: 4.5.13399 Compatibility Profile Context > 14.201.1006.1002 Then the check should pass, since 4.5 > 3.2 — but this is a compatibility profile, which means that asking for GLSL 1.20 should still succeed.
it probably should, but it's failing. when leaving this additional opengl 3.2 check it's throwing "Explicit version number 120 not supported by GL3 forward compatible context" error to the syslog - so it looks like the check is returning false and so it's using GLSL 1.2 and fails again
(In reply to Emmanuele Bassi (:ebassi) from comment #5) > (In reply to Giovanni Campagna from comment #2) > > Yes, this is a cogl bug. > > > > The shell should never use GL3.2, we use some GLSL shaders and we need the > > compatibility syntax, so we should only ask for 3.0 non-forward-compatible. > > No, this is a shell bug. The shell should use different shaders when running > against core 3.2 profiles and legacy ones. Mesa and nVidia are apparently a > lot more forgiving than the AMD driver when it comes to version selection, > but the Shell should stop behaving like OpenGL >3.2 does not exist. You don't get a core profile unless you ask for it - that's the point of profiles. We don't want to stop supporting 2.1, which means we'll have compat syntax, and there is little value in going to 3.2+ (we don't need transform feedback or geometry shaders), so why should we bother? The shell does not want a core profile (let alone a forward compat one!), and therefore should not get one, and the bug is in the component that asks for the context on the shell's behalf, ie, cogl.
(In reply to Giovanni Campagna from comment #15) > (In reply to Emmanuele Bassi (:ebassi) from comment #5) > > (In reply to Giovanni Campagna from comment #2) > > > Yes, this is a cogl bug. > > > > > > The shell should never use GL3.2, we use some GLSL shaders and we need the > > > compatibility syntax, so we should only ask for 3.0 non-forward-compatible. > > > > No, this is a shell bug. The shell should use different shaders when running > > against core 3.2 profiles and legacy ones. Mesa and nVidia are apparently a > > lot more forgiving than the AMD driver when it comes to version selection, > > but the Shell should stop behaving like OpenGL >3.2 does not exist. > > You don't get a core profile unless you ask for it - that's the point of > profiles. We don't want to stop supporting 2.1, which means we'll have > compat syntax, and there is little value in going to 3.2+ (we don't need > transform feedback or geometry shaders), so why should we bother? Because using core profiles, especially with Mesa, allows saving memory by dropping the backward compatibility API; there is a measurable difference in memory usage alone. You can safely fall back to a legacy profile if creating a core profile failed, and any GL-based application — including the shell — should have two code paths one for handling a core profile, and one for the legacy profile. > The shell does not want a core profile (let alone a forward compat one!), > and therefore should not get one, and the bug is in the component that asks > for the context on the shell's behalf, ie, cogl. I'd like to point out that the change to let Clutter ask for a core profile was started by a GNOME Shell developer, though I was happy to oblige, given that legacy profiles in 2015 should only be used as a fallback for older generations of hardware and for legacy code bases that are not maintained.
Could this work finally be accepted to unbreak gnome-shell 3.18 on fglrx systems? :) Here is another downstream report that confirms the patches fix this huge issue: https://bugs.gentoo.org/show_bug.cgi?id=567168 Thanks a lot
(In reply to Pacho Ramos from comment #17) > Could this work finally be accepted to unbreak gnome-shell 3.18 on fglrx > systems? :) Not until there's an answer for comment 13 — i.e. why the version check for 3.2 does not trigger.
Created attachment 317452 [details] [review] probably fixed Emmanuele's patch You probably made a typo, Emmanuele. I changed this line: if (COGL_CHECK_GL_VERSION (gl_major, gl_minor, 3, 2) && to: if (COGL_CHECK_GL_VERSION (ctx->glsl_major, ctx->glsl_minor, 3, 2) && and it works fine for me. The patch is in the attachement. Can someone confirm please?
(In reply to Vi0L0 from comment #19) > Created attachment 317452 [details] [review] [review] > probably fixed Emmanuele's patch > > You probably made a typo, Emmanuele. > I changed this line: > if (COGL_CHECK_GL_VERSION (gl_major, gl_minor, 3, 2) && > to: > if (COGL_CHECK_GL_VERSION (ctx->glsl_major, ctx->glsl_minor, 3, 2) && > and it works fine for me. > > The patch is in the attachement. > Can someone confirm please? Yes, it works
(In reply to Vi0L0 from comment #19) > Created attachment 317452 [details] [review] [review] > probably fixed Emmanuele's patch > > You probably made a typo, Emmanuele. No, I didn't. > I changed this line: > if (COGL_CHECK_GL_VERSION (gl_major, gl_minor, 3, 2) && > to: > if (COGL_CHECK_GL_VERSION (ctx->glsl_major, ctx->glsl_minor, 3, 2) && > and it works fine for me. You're checking for the GLSL version, and GLSL 3.2 does not exist.
Created attachment 322590 [details] [review] gl_Add_a_quirk_for_the_GLSL_version_to_use_on_AMD_v2.patch Attaching the patches used in Manjaro distribution to share efforts and not reinvent the wheel
Created attachment 322591 [details] [review] Use_better_vendor_strings_from_AMD.patch
I've spent adout 3 or more hours to find the solution for me. In the file cogl/cogl-glsl-shader.c there is line (100:) with next content: version_string = g_strdup_printf ("#version %i\n\n", ctx->glsl_version_to_use); I rewrote it with the next one (which means supported shader version for GLES 2.0): version_string = g_strdup_printf ("#version 330\n\n"); And everything works fine now. I don't know if it's a proper solution for every vendor, but with fglrx it works.
To wrap this up: There was a misunderstanding, that gnome-shell wants a core profile ctx but isn’t actually ready for it. It doesn’t even have to do with version numbers or drivers. (and i think tinkering with that is not a good solution) It went into a release undetected and the incompatibility manifested in this bug report. You can’t even blame catalyst/fglrx for its behavior on this one. Some people, especially with newer cards which aren’t supported by OSS radeon, have to use this driver. Two gnome releases are broken because of this. (have to be patched up downstream) That is truly saddening. Emmanuele: I’m all in for testing some patches, but concerning the above, I don’t believe there is anything which has to be tested at all.
(In reply to Norbert Pfeiler from comment #25) > To wrap this up: > There was a misunderstanding, that gnome-shell wants a core profile ctx but > isn’t actually ready for it. > It doesn’t even have to do with version numbers or drivers. (and i think > tinkering with that is not a good solution) > It went into a release undetected and the incompatibility manifested in this > bug report. > > You can’t even blame catalyst/fglrx for its behavior on this one. I can, and I will. It seems that it's asking for a specific version of GLSL regardless of which GL version is requested. > Two gnome releases are broken because of this. (have to be patched up > downstream) > That is truly saddening. What's truly saddening is that I asked a question in comment #13 in order to get a proper patch that does not regresses at random, and I got recrimination for doing my job properly, instead of dropping a bunch of code I cannot possibly verify. Anyway, Mutter has now switched to an internal copy of Cogl and Clutter, so if this bug affects GNOME Shell I'm going to re-assign it — and the Mutter maintainers can deal with it the way they see fit.
I’m sorry you got offended, people are just trying to make sense of the behavior. > OpenGL version string: 4.5.13399 Compatibility Profile Context 14.201.1006.1002 Was the output of fglrxinfo. What does it have to do with cogl and the assumption that cogl got a compatibility ctx too?
After taking a bit of time to find a way, i was able to retrieve the string returned from _cogl_context_get_gl_version(ctx), which is in fact: 3.1.13399 Core Profile Forward-Compatible Context 15.20.1046 whereas the fglrxinfo output is: OpenGL version string: 4.5.13399 Compatibility Profile Context 15.20.1046 Also, only version directives 110 and 120 throw errors.
Hi, is there something which can be done here? (still an issue with gnome 3.24)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.