[LINUX] Mesa uses wrong OpenGL version
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
[LINUX] Mesa uses wrong OpenGL version
NOTE: I'm reporting this bug for someone else, since they don't seem to have a ZDoom forums account (I don't really know), and I don't have the right hardware setup to test whether this bug is fixed or not. Also, the video will be gone in two weeks because of the way Twitch works.
At approximately the 31 minute mark on this video, you'll see a lot of textures turning black. A few minutes later, he turns off dynamic lights, and the textures stop turning black. There are also some similar glitches at around the 24 minute mark.
AFAIK, the person who was streaming this has an AMD graphics card, and he was using the open-source AMDGPU drivers (I don't know for sure. He could have been using the Radeon/RadeonSI drivers for all I know).
UPDATE: I think it's because Mesa3D uses an older version of OpenGL by default. See this.
At approximately the 31 minute mark on this video, you'll see a lot of textures turning black. A few minutes later, he turns off dynamic lights, and the textures stop turning black. There are also some similar glitches at around the 24 minute mark.
AFAIK, the person who was streaming this has an AMD graphics card, and he was using the open-source AMDGPU drivers (I don't know for sure. He could have been using the Radeon/RadeonSI drivers for all I know).
UPDATE: I think it's because Mesa3D uses an older version of OpenGL by default. See this.
Last edited by Talon1024 on Mon Jul 03, 2017 1:13 am, edited 6 times in total.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Graphical glitches with AMDGPU
Sounds like a graphics driver issue.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
-
- Posts: 13793
- Joined: Tue Jan 13, 2004 1:31 pm
- Preferred Pronouns: She/Her
Re: [LINUX] Graphical glitches with AMDGPU
That's definitely a driver/hardware issue.
Try -glversion 2 and see if it fixes anything.
Also, can you post your startup log? You can do that by redirecting stdout i.e. "gzdoom -file whatever>file.txt"
Try -glversion 2 and see if it fixes anything.
Also, can you post your startup log? You can do that by redirecting stdout i.e. "gzdoom -file whatever>file.txt"
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [LINUX] Graphical glitches with AMDGPU
I got the exact same graphical glitches on a Linux laptop with an Intel integrated graphics card. I tried the following fixes/workarounds:
EDIT: I just tried an earlier build of GZDoom (g3.0pre-200-gebf3a37 to be precise), and the aforementioned glitches did not occur. I was also able to use the newfangled OpenGL features, such as tonemapping. I was unable to use tonemapping with the build I used in the above log.
- adding -glversion 2 to command line parameters (did not work)
- adding -glversion 3 to command line parameters (did not work)
- setting gl_es to 1 (made the game unable to start up)
Code: Select all
GZDoom g3.2pre-104-ge19c8eb - 2017-07-01 23:55:41 +0200 - SDL version
Compiled on Jul 1 2017
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
adding /home/kevinc/Games/doom/gzdoom-master-20170701/gzdoom.pk3, 717 lumps
adding /home/kevinc/Games/doom/IWADS/DOOM2.WAD, 2919 lumps
adding lights.pk3, 6 lumps
adding brightmaps.pk3, 500 lumps
adding ../MusicPacks/Doom2PK3.pk3, 22 lumps
adding /media/kevinc/OS/Games/doom/gzdoom/Doom2Mods/boa_c2.pk3, 14296 lumps
I_Init: Setting up machine state.
CPU Vendor ID: GenuineIntel
Name: Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz
Family 6, Model 58, Stepping 9
Features: SSE2 SSE3 SSSE3 SSE4.1 SSE4.2
I_InitSound: Initializing OpenAL
Opened device Built-in Audio Analog Stereo
EFX enabled
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 396.41 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
a Realm667 project
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver x11
GL_VENDOR: Intel Open Source Technology Center
GL_RENDERER: Mesa DRI Intel(R) Ivybridge Mobile
GL_VERSION: 3.0 Mesa 17.1.2 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: 1.30
Max. texture size: 16384
Max. texture units: 16
Max. varying: 128
Resolution: 1366 x 768
titlemap - TITLEMAP
intromap - Introduction
]map c1m2
c1m2 - Operation: Exodus
You got a field kit.
c2m1 - Operation: Ausbruch
Game saved. (/home/kevinc/.config/gzdoom/auto1.zds)
Picked up a coin.
Picked up a coin.
Picked up a bag of coins.
Game saved. (/home/kevinc/.config/gzdoom/auto2.zds)
Picked up a bowl of dog food.
Picked up a bowl of dog food.
Picked up some bandages.
Picked up a grenade.
You found a combat knife.
Stealth Kill!
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Graphical glitches with AMDGPU
The mimimum requirement has been upped to GL 3.3 to expose all features because on most drivers anything less causes major problems on most hardware.
This setup will get forced to the legacy render path.
I have absolutely no idea why these open source drivers restrict themselves to GarbageGL, even on better hardware. GZDoom requires *MODERN* OpenGL to work properly, preferably version 4.x. With these drivers they are totally amputating the hardware they run on. Or is this an SDL problem which tries to force a compatibility context, even if the hardware supports the core profile? Something along those lines seems more likely but that needs to be investigated by someone with Linux and affected hardware. As long as you only get OpenGL 3.0 you won't get proper feature support.
This setup will get forced to the legacy render path.
I have absolutely no idea why these open source drivers restrict themselves to GarbageGL, even on better hardware. GZDoom requires *MODERN* OpenGL to work properly, preferably version 4.x. With these drivers they are totally amputating the hardware they run on. Or is this an SDL problem which tries to force a compatibility context, even if the hardware supports the core profile? Something along those lines seems more likely but that needs to be investigated by someone with Linux and affected hardware. As long as you only get OpenGL 3.0 you won't get proper feature support.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [LINUX] Graphical glitches with AMDGPU
I don't know why Mesa3D used OpenGL 3.0 as the default either. I think all graphics drivers should use the maximum versions of whatever graphics API that the graphics card supports as the default.
Anyway, I found a fix here on AskUbuntu.
Anyway, I found a fix here on AskUbuntu.
Code: Select all
MESA_GL_VERSION_OVERRIDE=3.3 command
-
- Posts: 2954
- Joined: Thu Jul 17, 2003 12:07 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: [LINUX] Graphical glitches with AMDGPU
As I understand it, with higher OpenGL versions core profiles deprecate older features, which can break compatibility if a vendor makes said features unavailable. This is to help remove the overhead of, or issues related to, fixed-function processing since newer versions are completely programmable with closer hardware access. You have to explicitly request a core profile (and not use any fixed-function calls) if you really want to take advantage of the latest and greatest OpenGL. Otherwise you get a compatibility profile which may not have everything, or not be very efficient with what it does give.I don't know why Mesa3D used OpenGL 3.0 as the default either. I think all graphics drivers should use the maximum versions of whatever graphics API that the graphics card supports as the default.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Graphical glitches with AMDGPU
Well, looking into it, it seems that SDLGLVideo::SetupPixelFormat doesn't specify the desired profile and GL version.
On Windows it's similar: If no core profile is specified, you get the best GL version for a compatibility profile, and for a core profile you only get what you ask for, never anything better, so I think the same needs to be done here.
Someone with the ability to test really should set this up properly, it looks like the Mesa driver won't return anything useful unless being given proper instructions.
On Windows it's similar: If no core profile is specified, you get the best GL version for a compatibility profile, and for a core profile you only get what you ask for, never anything better, so I think the same needs to be done here.
Someone with the ability to test really should set this up properly, it looks like the Mesa driver won't return anything useful unless being given proper instructions.
-
-
- Posts: 375
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [LINUX] Mesa uses wrong OpenGL version
So, I changed lines 362-371 of sdlglvideo.cpp to this:
This fixes the immediate issue I was having, but breaks -glversion.
Code: Select all
if (gl_es)
{
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 2);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
} else {
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_CORE);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 3);
}
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Mesa uses wrong OpenGL version
Obviously this needs a bit more intelligence but it's good to see that my hunch was correct.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Mesa uses wrong OpenGL version
So, nobody here who can implement it properly and has a system to test on?
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: [LINUX] Mesa uses wrong OpenGL version
I can implement this but I have no system to test on and virtual machines are too limited in supported versions on OpenGL.
On macOS core context is requested first and if its creation fails compatibility one is used.
On macOS core context is requested first and if its creation fails compatibility one is used.
-
- Lead GZDoom+Raze Developer
- Posts: 49183
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [LINUX] Mesa uses wrong OpenGL version
The main issue is that I have no idea what happens if you request a version lower than the maximum.
On Windows, requesting a core profile context may only give you one with the precise version number you request, so the only way to get the best is to check all supported versions, from the best, down to the mimmum supported.
On Windows, requesting a core profile context may only give you one with the precise version number you request, so the only way to get the best is to check all supported versions, from the best, down to the mimmum supported.
-
-
- Posts: 3819
- Joined: Sun Aug 07, 2011 4:32 am
Re: [LINUX] Mesa uses wrong OpenGL version
Probably this depends on drivers. I think it's possible to request core profile first without specifying exact version, check if it's 3.3 and if it's below (or if context creation failed at all) fallback to compatibility profile.