Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

[delroth]

New article on the Dolphin Blog: Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

Feel free to discuss the article on this thread.

[rokclimb15]

Excellent. I love reading articles like this that shed light into the Dolphin developer experience. AMD has been less than responsive regarding driver issues on Windows as well, some of them significant and breaking rendering in modern web browsers.

[romainguy]

That was a very interesting article, thank you.

I work on the Android team at Google and I ran into similar issues when working with PBOs on Mali and Adreno drivers. The two main problems I experienced were poor performance on mapping (Mali and Adreno) and data corruption on upload (Adreno). Both issues have been fixed in the drivers that will ship with Android 4.4 KitKat.

I have been trying to use as many OpenGL ES 3.0 features as I could in the rendering pipeline used by our UI toolkit/2D drawing API. My goal was not only to optimize our renderer but to also find bugs like these and get them fixed as soon as possible. There are still a few ES 3.0 features that I haven't had time to put to good use unfortunately (UBOs for instance.)

[delroth]

That's great news! Thanks for helping make drivers less buggy

[Optimis0r]

Brilliant read. I love insightful articles like these. Hope you guys can write more stuff like this.

[arnebef]

Hi,

I am an software engineer working for ARM on the GPU driver - thanks for a great article and and for pointing out places to improve ourselves

Just a few comments:

Quote:Clearing color with glClear kills performance as if the drivers waits for completion of the clear when it should be mostly asynchronous. Sometimes glClear takes more than 1/60th of a second (a full frame!) to complete, making it completely unusable. This has been reported by other Android developers too: on the Ouya forums or on StackOverflow.

If you look at the answer on the StackOverflow question ( http://stackoverflow.com/a/12236102 ), it is mostly explained there why this happens. To not allow the game to progess too far ahead of VSYNC, the GPU driver must block somewhere.

Quote: The Mali shader compiler does not support global shader variables which aren’t constant. This is a violation of the OpenGL ES 3.0 standard, but an easy fix on our side.

Could you post the shader that this fails on - either here or on http://malideveloper.arm.com - and how it fails (if it is a compilation failure or a runtime failure)?

[neobrain]

(09-27-2013, 05:56 PM)arnebef Wrote: Hi,

I am an software engineer working for ARM on the GPU driver - thanks for a great article and and for pointing out places to improve ourselves

Hi, thanks for your feedback
I'm one of the devs working on the GPU emulation code, so I'd like to address one of your points. I should probably mention that I'm not as familiar with OpenGL as I am with D3D, so I hope my comment isn't too uninformed

(09-27-2013, 05:56 PM)arnebef Wrote: Just a few comments:

Quote:Clearing color with glClear kills performance as if the drivers waits for completion of the clear when it should be mostly asynchronous. Sometimes glClear takes more than 1/60th of a second (a full frame!) to complete, making it completely unusable. This has been reported by other Android developers too: on the Ouya forums or on StackOverflow.

If you look at the answer on the StackOverflow question ( http://stackoverflow.com/a/12236102 ), it is mostly explained there why this happens. To not allow the game to progess too far ahead of VSYNC, the GPU driver must block somewhere.

So what would happen if we called glFinish each time a frame ends? It's highly likely that it would call glFinish at a different frequency than 30/s (depending on the emulated game). We'd still potentially call glClear various times, but maybe the driver is smart enough to not block at the first few glClear calls in a frame?

Anyway, I'm not sure I completely understand what the issue is in the first place. I was thinking that you could just force a pipeline flush in your driver when calling eglSwapBuffers, but I guess that won't work because if the whole command stream were to be processed when calling eglSwapBuffers, it might be already too late to hit vsync properly. Do I understand this correctly?

EDIT: Moved to PM, keeping text for reference.

[Arbee]

Hi Delroth,

Great article. Hopefully this will improve the future state of OpenGL on Linux.

When I started the current OpenGL path for MAME/MESS in 2006, my first version which simply blitted a textured quad (straight GL 1.0 out of the original NeHe) would cause a kernel panic on machines running ATI's fglrx driver. Nvidia and Mesa drivers worked fine, of course. Things are much better now - you can use shaders even on fglrx with a reasonable expectation that something approximately correct will happen, but it's still not the It Just Works that you normally get from the Nvidia blob.

Regarding OS X, Apple didn't trust the GPU makers and so they write their own drivers. There's a shared OpenGL stack functionally similar to Mesa and a series of chip-specific back ends using LLVM to compile the shaders. This means that for OpenGL bugs on OS X you report them to Apple via their Radar bug tracking system instead of the specific GPU vendor.

[2muchjpop]

(09-26-2013, 11:58 PM)delroth Wrote: New article on the Dolphin Blog: Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

Feel free to discuss the article on this thread.

Actually at the end of the article the link to the pcsx2 benchmark doesn't really help much because i have a 8350 stock with 7970 ghz edtion and the instruction sets on the 8350 are improved which got rid of any lag i might have had with my 1090t before and while the bulldozer series didn't offer much the 8350 is actually a good upgrade and performs on par with 3570k if the setttings are set up correctly. also, i have some random games i like to keep to test how the APIs work. i tried the spongebob movie game with open gl and dx11 and this time dx11 actually worked better. i also tried a mainstream game (ssbm) and dx11 worked better in this case as well. So processor wise amd is not a bad choice to go with if you have the current one available. and as for the graphics i don't know if it's an amd thing but open gl didn't look polished or refined as dx11 did. however i believe that dolphin is making good strides towards improvement. waiting for steam os to come out so i can install a nice version of linux which can also game. will have to wait for that before i can comment on linux drivers.

[delroth]

74.59 FPS - SLUS 20672 - Intel Core i5 3570K - 3.4 GHz Stock (3.7 GHz w/TB) - Shadow Lady - CPU-Z
61.11 FPS - SLUS 20672 - AMD FX-8350 - 4.0 GHz Stock (4.1 GHz w/TB) - azerty16 - CPU-Z

No, it doesn't perform "on par". While there is definitely improvement (first time an AMD CPU gets over 60FPS on this benchmark at stock clock), AMD CPUs are still a horrible choice for emulation. Obviously it doesn't matter when you're GPU bound.