• Login
  • Register
  • Dolphin Forums
  • Home
  • FAQ
  • Download
  • Wiki
  • Code


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Site › dolphin-emu.org articles v
« Previous 1 2 3 Next »

Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame
View New Posts | View Today's Posts

Pages (3): 1 2 3 Next »
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame
09-26-2013, 11:58 PM
#1
delroth Offline
Making the world a better place through reverse engineered DSP firmwares
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,354
Threads: 63
Joined: Aug 2011
New article on the Dolphin Blog: Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame

Feel free to discuss the article on this thread.
Pierre "delroth" Bourdon - @delroth_ - Blog

<@neobrain> that looks sophisticated enough to not be a totally dumb thing to do
Website Find
Reply
09-27-2013, 12:45 AM
#2
rokclimb15 Offline
Senior Member
****
Posts: 383
Threads: 4
Joined: Jul 2013
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.
Find
Reply
09-27-2013, 04:56 AM
#3
romainguy
Unregistered
 
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.)
Reply
09-27-2013, 05:16 AM
#4
delroth Offline
Making the world a better place through reverse engineered DSP firmwares
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,354
Threads: 63
Joined: Aug 2011
That's great news! Thanks for helping make drivers less buggy Smile
Pierre "delroth" Bourdon - @delroth_ - Blog

<@neobrain> that looks sophisticated enough to not be a totally dumb thing to do
Website Find
Reply
09-27-2013, 08:13 AM
#5
Optimis0r Offline
Junior Member
**
Posts: 32
Threads: 2
Joined: Aug 2013
Brilliant read. I love insightful articles like these. Hope you guys can write more stuff like this.
Find
Reply
09-27-2013, 05:56 PM
#6
arnebef
Unregistered
 
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 Smile

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)?
Reply
09-27-2013, 10:16 PM (This post was last modified: 09-28-2013, 06:35 AM by neobrain.)
#7
neobrain Offline
"Wow, I made my code 1000x faster! That means I can make it 2048x slower now!"
**********
Developers (Some Administrators and Super Moderators)
Posts: 3,208
Threads: 50
Joined: Jun 2009
(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 Smile

Hi, thanks for your feedback Smile
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 Wink

(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.
My blog
Me on Twitter
My wishlist on Amazon.de
Find
Reply
09-28-2013, 01:41 AM
#8
Arbee
Unregistered
 
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.
Reply
09-29-2013, 12:27 AM
#9
2muchjpop
Unregistered
 
(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.
Reply
09-29-2013, 01:36 AM (This post was last modified: 09-29-2013, 01:36 AM by delroth.)
#10
delroth Offline
Making the world a better place through reverse engineered DSP firmwares
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,354
Threads: 63
Joined: Aug 2011
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.
Pierre "delroth" Bourdon - @delroth_ - Blog

<@neobrain> that looks sophisticated enough to not be a totally dumb thing to do
Website Find
Reply
« Next Oldest | Next Newest »
Pages (3): 1 2 3 Next »


  • View a Printable Version
  • Subscribe to this thread
Forum Jump:


Users browsing this thread: 1 Guest(s)



Powered By MyBB | Theme by Fragma

Linear Mode
Threaded Mode