[Fixed] [LINUX] Mesa uses wrong OpenGL version

Bugs that have been investigated and resolved somehow.

Moderator: Developers

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Chris » Tue Jul 11, 2017 4:26 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Graf Zahl » Tue Jul 11, 2017 5:04 pm

Chris wrote: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Chris » Wed Jul 12, 2017 1:14 am

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.
Attachments
sdlgl-patch.txt
(4.95 KiB) Downloaded 49 times
User avatar
Chris
 
Joined: 17 Jul 2003

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Graf Zahl » Wed Jul 12, 2017 1:27 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Chris » Wed Jul 12, 2017 2:52 am

Graf Zahl wrote: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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Graf Zahl » Wed Jul 12, 2017 3:56 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [LINUX] Mesa uses wrong OpenGL version

Postby _mental_ » Thu Jul 13, 2017 10:28 am

Patch seems to work fine.

Without it I've got the following in startup log:
Code: Select allExpand view
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 allExpand view
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 allExpand view
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 allExpand view
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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Chris » Thu Jul 13, 2017 4:51 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Graf Zahl » Thu Jul 13, 2017 4:54 pm

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [LINUX] Mesa uses wrong OpenGL version

Postby _mental_ » Fri Jul 14, 2017 1:40 am

Chris wrote: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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Talon1024 » Fri Jul 14, 2017 3:50 am

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.
Talon1024
 
 
 
Joined: 27 Jun 2016

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Chris » Sat Jul 15, 2017 10:47 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: [LINUX] Mesa uses wrong OpenGL version

Postby _mental_ » Sun Jul 16, 2017 1:49 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: [LINUX] Mesa uses wrong OpenGL version

Postby Graf Zahl » Sun Jul 16, 2017 2:21 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [LINUX] Mesa uses wrong OpenGL version

Postby _mental_ » Sun Jul 16, 2017 2:39 am

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.
_mental_
 
 
 
Joined: 07 Aug 2011

PreviousNext

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests