[LINUX] Mesa uses wrong OpenGL version

[Chris]

Requesting a core profile without a version doesn't make sense to me. Since newer versions can deprecate old functionality, it would be possible for you to get a much newer core version that disables some functionality GZDoom uses. Specifying a version would tell the driver what functionality you need, and can then provide the best GL version that it can give that functionality with.

I can play around with requesting core profiles. But since I'm not too familiar with doing that (haven't really directly used core OpenGL stuff much), and I don't have an affected system, other people will have to test any patches to see if it fixes this issue without breaking anything.

[Graf Zahl]

Since newer versions can deprecate old functionality, it would be possible for you to get a much newer core version that disables some functionality GZDoom uses.

Correct. So the only way to get the best supported version is to start with 4.5 and test every version down to 3.3 until the context creation succeeds. Windows is doing the exact same thing.
That said, the entire approach is utterly stupid. A sane method would have been to pass in a minimum and maximum version that can be handled, not letting the caller poke around in the dark.

[Chris]

I've attached a patch to try and request a core context for OpenGL 4.x, 3.3, and 3.2 (profiles were added with GL3.2, so it doesn't make sense to me to try core profiles for 3.1 and 3.0). If none of them work, it'll request a 2.0 compatibility profile. On my system, this gives me a 4.5 core profile which works just fine, and it also works to use the -glversion switch for an earlier GL version like 4.1 or 3.3 (with the caveat that '-glversion 3' is treated as requesting GL 3.0, which isn't supported so it goes for the next lower version, a GL 2.x compatibility profile; you'd need to specify -glversion 3.2 or higher to have it try for GL3).

I would prefer if others can test it with various cards that support older GL versions, as well as those that only support 2.1+FBOs (I don't know how SDL will act when requesting a 2.0 compatibility profile on drivers that don't even support profiles added by 3.2; hopefully SDL will just ignore the profile flag since it's for a compatibility context anyway). Assuming it works out satisfactorily, I can make a PR for it.

[Graf Zahl]

Regarding -glversion, in Windows I changed it so that 3.0 forces the minimal requirement for 3.x, i.e. 3.0.
Do we even need 3.2? AFAIK the Linux driver for Intel HD3000 supports OpenGL 3.3.

[Chris]

Regarding -glversion, in Windows I changed it so that 3.0 forces the minimal requirement for 3.x, i.e. 3.0.

Hmm, looking more through the code, it seems 3.3 is the minimum requirement for the "modern render path". Does it make sense to handle GL 3.2, 3.1, and 3.0 since it's dropping to the legacy path anyway (which I assume uses the fixed-function pipeline)? In that case, it's no better than a 2.1 compatibility profile.

Interestingly, if I try to do -glversion 3.2 with this patch it gives me a 3.2 compatibility profile (according to GZDoom's startup log), which is odd since it set the core profile flag during context creation. Further, rendering was broken (the title screen was completely black), as if the legacy fallback renderer was failing to draw. If I do -glversion 3.3, it correctly reports a 3.3 core profile and rendering works, and with -glversion 2 I get a compatibility profile which also renders fine.

Do we even need 3.2? AFAIK the Linux driver for Intel HD3000 supports OpenGL 3.3.

Probably not. I just read that the core/compatibility profile flags were added with 3.2 and I didn't see a reason to exclude it. Now that I see 3.3 is required for the modern render path, and the legacy render path relies on a compatibility profile, I can drop that version from auto-detection.

[Graf Zahl]

It would be better, I think. Although the engine can nominally work on GL 3.0 with a few extensions, there's a few issues, most notably shader compile problems with some buggy drivers. Making 3.3 the requirement for the modern path should eliminate all of those.

[_mental_]

Patch seems to work fine.

Without it I've got the following in startup log:

Code: Select all

GL_VERSION: 3.0 Mesa 12.0.6 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: 1.30

With the patch Core Profile was enabled:

Code: Select all

GL_VERSION: 3.3 (Core Profile) Mesa 12.0.6 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 3.30

Common part was like this:

Code: Select all

Using video driver x11
GL_VENDOR: X.Org
GL_RENDERER: Gallium 0.4 on AMD RV710 (DRM 2.43.0 / 4.4.0-83-generic, LLVM 3.8.0)

I was testing using notebook with Mobility Radeon 4330 and up-to-date Linux Mint 18.
The problem is that with Core Profile there was only black screen and infinite stream of errors in Terminal:

Code: Select all

EE ../../../../../src/gallium/drivers/r600/r600_shader.c:182 r600_pipe_shader_create - translation from TGSI failed !
EE ../../../../../src/gallium/drivers/r600/r600_state_common.c:798 r600_shader_select - Failed to build shader variant (type=1) -1

Most likely ATI drivers for this graphics hardware is broken on Linux too.

[Chris]

Don't suppose there's an error from GZDoom about why a shader failed to compile? Perhaps by passing +gl_debug 1 +gl_debug_level 3.

[Graf Zahl]

Those error messages by the driver are truly not helpful. This actually looks like a bug in the compiler rather than something in the shader source the driver stumbles on.

[_mental_]

Don't suppose there's an error from GZDoom about why a shader failed to compile? Perhaps by passing +gl_debug 1 +gl_debug_level 3.

The output remains the same with this command line parameters. Similar issues were already reported before and switching to legacy render path was the only way to workaround the black screen.

[Talon1024]

Have you tried using a newer version of Mesa? Maybe you can upgrade to the latest Mesa drivers using the PPA referenced in this article.

[Chris]

So what should happen with this patch, then? It doesn't seem like a good outcome for auto-selecting a core profile to cause some Radeon devices to fail with a black screen, requiring the user to explicitly pass -glversion 2. It wouldn't even be possible to detect when selecting the renderer, since the core profile doesn't allow access to the fixed-function pipeline used by the legacy renderer. Unless you just want to tell the Mesa/Gallium devs to fix it.

[_mental_]

I doubt that somebody will fix drivers for eight years old hardware.

OpenGL 3.3 is available on Windows and drivers compile shaders just fine.
Although rendering is completely broken: missing sprites and constant flickering make the game unplayable.
Older drivers with OpenGL 3.1 support simply crashes on attempt to compile the first shader.

So my case is hardly a platform specific issue, it's rather 'lame vendor' specific.

[Graf Zahl]

The bigger issue here is not this specific hardware but that AMD is abandoning their proprietary driver on Linux entirely and Intel is also depending on MESA which does not implement compatibility profiles at all. Something needs to be done here to ensure that future hardware isn't forced to the legacy path.

To be blunt: I think the only way to solve this mess is to generally force all AMD/ATI hardware which does not return a GL 4.4 context down to legacy. I know that this is ridiculous but what else can we do? This long deprecated hardware's drivers just seem too broken across the board.

@_mental_: Can you post the Windows startup log? That blinking stuff error's cause is known and the feature responsible normally disabled when running an ATI driver, but maybe the check is incomplete.

[_mental_]

Unfortunately I don't have startup logs because it was a year ago or something like that on Windows 10.
I installed Windows 7 after HDD replacement but the latest AMD drivers have unrelated severe issues making them unusable for me.
Drivers from notebook's vendor are OK more or less but they support OpenGL 3.1 only and so GZDoom falls back to legacy render path.