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


Dolphin, the GameCube and Wii emulator - Forums › Dolphin Emulator Discussion and Support › Development Discussion v
« Previous 1 ... 47 48 49 50 51 ... 115 Next »

OpenGL performance on Graphic_Update branch
View New Posts | View Today's Posts

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Modes
OpenGL performance on Graphic_Update branch
12-06-2012, 10:14 PM
#1
degasus Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,827
Threads: 10
Joined: May 2012
Hello

I made a cpu usage profile of the gpu thread in SMG:

uploading vertices: 1461 usecs per frame
uploading intices: 347 usecs per frame
DrawVertexBufferObjectBase: 2672 usecs per frame
DrawVertexBufferObjectBase_AlphaPass: 674 usecs per frame

I see, uploading needs time, but shouldn't the draw command be asynchronous?

At all, this 4 commands would need 31% of the cpu at 60 fps ...

btw, there are 429 indexed draws (177 with alpha pass), so every draw command needed 6.2 usecs. Is this usual?
Find
Reply
12-06-2012, 11:23 PM
#2
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,209
Threads: 50
Joined: Jun 2009
That's why I said built-in profilers suck; GPU drivers delay any operation as long as they can, and this includes RAM->VRAM transfers.

What you're probably seeing is that a vertex buffer was still in use when we tried writing new data into it. The GPU driver likely delayed the actual RAM->VRAM upload to the next DrawPrimitive() call, which is why you see so much CPU time spent there.

.. Or it's just the typical case that the CPU says "Yo GPU, here's some data to draw" and the GPU answers "Yo dawg, I'm still busy so wait a minute with that data".
My blog
Me on Twitter
My wishlist on Amazon.de
Find
Reply
12-06-2012, 11:47 PM (This post was last modified: 12-07-2012, 12:21 AM by degasus.)
#3
degasus Offline
Developer
**********
Developers (Some Administrators and Super Moderators)
Posts: 1,827
Threads: 10
Joined: May 2012
(12-06-2012, 11:23 PM)neobrain Wrote: What you're probably seeing is that a vertex buffer was still in use when we tried writing new data into it. The GPU driver likely delayed the actual RAM->VRAM upload to the next DrawPrimitive() call, which is why you see so much CPU time spent there.
But the draw command should also be delayed? In fact, adding much sleeps between uploading and drawing doesn't change this timings.

(12-06-2012, 11:23 PM)neobrain Wrote: .. Or it's just the typical case that the CPU says "Yo GPU, here's some data to draw" and the GPU answers "Yo dawg, I'm still busy so wait a minute with that data".
A secound identical draw command will return directly, so I guess, this is not the reason.

btw, after switching the shader, the draw command use double the time. So it is perhaps changing the state of the pipeline?

Edit: enabling USE_DUAL_SOURCE_BLEND, the secound draw command isn't used anymore and (more importend) the shader won't be changed for this. So the shader sometimes don't need to be changed befor the regular call. So the total time spend on draw commands (1856usec) is now lower than the time spend on the frist draw command without alphapass.
Find
Reply
« Next Oldest | Next Newest »


  • 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