New AMD driver and slow hardware accelerated OpenGL ES

Bugs that have been investigated and resolved somehow.

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.
Rubiko
Posts: 1
Joined: Wed Jul 27, 2022 10:48 am

New AMD driver and slow hardware accelerated OpenGL ES

Post by Rubiko »

AMD has recently released the new driver (Adrenalin 22.7.1) that boosts the OpenGL overall performance and indeed GZDoom's OpenGL rendering API runs much faster now. On the other hand, OpenGL ES + Hardware accelerated renderer mode runs very slow (OpenGL ES + Doom Software Renderer is still very fast).

GZDoom 4.8.2; Windows 10 21H1 x64; Radeon Vega 8
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Graf Zahl »

Can you please get some large map with a lot of render action (e.g. Frozen Time when you get to the bridge), do a savegame there and then make a screenshot while 'stat rendertimes' is active and post them here? I'd like to see the values you get.

One thing though: GLES will inevitably be slower on modern hardware. It trades shader complexity for a larger number of shaders. That will be faster on old hardware where shader throughput is the bottleneck, but on modern hardware the constant shader switches will take quite a toll. This backend is not meant for modern hardware.
User avatar
Rachael
Admin
Posts: 12911
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Rachael »

I'll test this on my RX 550 with both the Studio drivers I am using now and with the new driver update. (I am actually kind of curious about this update myself anyway, as I have several OpenGL apps that I use on this computer that happens to use an AMD)

Should probably note - my card is a discrete GPU - Vegas (like the OP has) are integrated APU units, which might be why they prefer GLES mode. But their thing can do Vulkan, anyway.
dpJudas
 
 
Posts: 2861
Joined: Sat May 28, 2016 1:01 pm

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by dpJudas »

Well, what graf said about shader also apply to Vulkan. The price for switching between the shaders is less than in OpenGL though. Vulkan was designed around being able to switch between pipelines much cheaper than in OpenGL.
User avatar
Rachael
Admin
Posts: 12911
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Rachael »

Alright the results are in - and the differences are so drastic it's night and day on the moon.

Note that I forgot to turn off vid_maxfps with these tests but the driver took so long to install it really did not seem to be worth it to switch back, but I am hoping the drawcall numbers will still give enough accuracy to shed some light on this.

I did a Vulkan test first, to establish a baseline and a frame of reference. All of my screenshots can be found on this gist: (warning, it's very 1080p image heavy)

https://gist.github.com/madame-rachelle ... e4c16ecf4d

The Finish call is what's eating up all the time. It slows the rest of the system to a crawl, too, so this is very very clearly a driver bug.

For what it's worth though - the new OpenGL driver can *finally* handle models correctly, again! So the shader compilation/optimization bug was fixed. Elder Jam worked as intended in OpenGL and it's no longer necessary to use GLES for older AMD cards.
User avatar
Exl
Posts: 20
Joined: Wed Jul 01, 2009 5:22 am

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Exl »

This isn't useful anymore, but out of curiosity I checked the differences for myself. I tested on modern hardware so the absolute OpenGL ES results mean nothing, but the relative results are still quite something; it is now unplayable. Vulkan is slightly slower, and OpenGL got a nice boost indeed from 11.2ms down to 6.666ms total time. :twisted:

Vulkan before & after
OpenGL before & after
OpenGL ES before & after
dpJudas
 
 
Posts: 2861
Joined: Sat May 28, 2016 1:01 pm

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by dpJudas »

That 1 fps of the last picture make me laugh. :D

By the way - what's up with the high variance in draw call numbers in the stats? Shouldn't those be roughly the same for the same scene?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Graf Zahl »

That's time values, not call numbers. It's a good measurement for driver efficiency. Good to see that AMD finally managed to get them down for OpenGL.
User avatar
Rachael
Admin
Posts: 12911
Joined: Tue Jan 13, 2004 1:31 pm
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Preferred Pronouns: She/Her

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Rachael »

Those results are weird. For me the problem in OpenGLES was the Finish.

My render numbers were fine for the bridge in Frozen Time but for Exl's screenshot they're abysmal in the setup and even worse in the render.

This is clearly an issue inside the driver itself, either way - you can reliably get real shitty numbers in OpenGLES with AMD and it seems GZDoom does not have the proper tools within itself to diagnose the actual problems within the driver.

But the OpenGL improvements are still clearly a win - improvements on those include the frame rate boost obviously, but also model support has finally been repaired.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: New AMD driver and slow hardware accelerated OpenGL ES

Post by Graf Zahl »

Rachael wrote:Those results are weird. For me the problem in OpenGLES was the Finish.
Actually, the problem is a GPU stall. This can happen in all places where the state changes.
Rachael wrote:This is clearly an issue inside the driver itself, either way - you can reliably get real shitty numbers in OpenGLES with AMD and it seems GZDoom does not have the proper tools within itself to diagnose the actual problems within the driver.
No, we can't. It's too far inside the driver, where we cannot look at.
Rachael wrote: But the OpenGL improvements are still clearly a win - improvements on those include the frame rate boost obviously, but also model support has finally been repaired.
Oh yes. But it won't really help us that much.
AMD has already abandoned all hardware that does not support Vulkan, so on this no improvement can be seen.

But I really think we need to be smarter about what backends to offer. I'd really consider blocking GLES for Vulkan compatible hardware and only offer one of these as an alternative to OpenGL.
From other discussions I have seen that many do their benchmarking on E1M1 or MAP01 and see 300 fps more for GLES due to its altered frame timing and erroneously derive from that it is the preferable backend for their high end hardware, never realizing how feature stripped it really is.

Return to “Closed Bugs”