Jump to content

  • Log In with Google      Sign In   
  • Create Account


Performance issues with IDXGISwapChain::Present


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Wh0p   Members   -  Reputation: 177

Like
0Likes
Like

Posted 04 October 2013 - 11:54 AM

Hi,
I have implemented a deferred renderer for some time and now i started to profile a little.
Right now I am kind of dissappointed for the following reason:
 
My test scene looks like this, some Geometry with 100 pointlights moving in circles:
IrtNVMx.png
Y68l44U.png
 

The values for rendering buffers and lights and updating are ok by me.
It throws me off that the Present call consumes that much time. Im calling it this way: Present(0, 0) - so it should be rendered as fast as possible.

Here are the Profiling results:



















































closefar
FPS14.527
Update/Render8.14.7(Time updating the scene and rendering combined just for doublechecking)
Present57.530(The SwapChain::Present call)
UpdateScene 3.72.2(Updating scene only)
UpdateLights 0.50.3(Updating light buffers)
G-Buffer21.2(Rendering G-Buffer)
SSAO 1.51.0(Rendering SSAO + Blur)
RenderLights 10.5(Rendering Lights)

Edited by Wh0p, 04 October 2013 - 11:55 AM.


Sponsor:

#2 Juliean   GDNet+   -  Reputation: 1893

Like
1Likes
Like

Posted 04 October 2013 - 12:00 PM

It throws me off that the Present call consumes that much time. Im calling it this way: Present(0, 0) - so it should be rendered as fast as possible.

Present almost always will take up the most time, since the application has to wait for the card to finish rendering entirely before it can presume, even without VSYNC. You need to use a specialized GPU debugging tool (PIX, nsight, the one integrated in VS2012) in order to see where the work is really happening.

 

Besides, 100 spotlights is (AFAIK) a huge value, even for a deferred renderer. How many passes does that take? Do you draw multiple lights in one pass, or does each light take its own rendering pass?



#3 MJP   Moderators   -  Reputation: 8746

Like
1Likes
Like

Posted 04 October 2013 - 12:14 PM

When the GPU is taking longer than the CPU, Present will start to block once the CPU is a few frames ahead (default number is 3, can be adjusted with IDXGIDevice1::SetMaximumFrameLatency). The driver has to do this, otherwise the CPU could get infinitely far ahead of the GPU and the driver would have to buffer a gigantic number of commands for the GPU to consume. Its not like you'd actually want your game simulation to be that far ahead anyway.

Like Juliean mentioned, you need to profile the GPU here and not the CPU to know where your performance issues are.



#4 Wh0p   Members   -  Reputation: 177

Like
0Likes
Like

Posted 04 October 2013 - 04:07 PM

Besides, 100 spotlights is (AFAIK) a huge value, even for a deferred renderer. How many passes does that take? Do you draw multiple lights in one pass, or does each light take its own rendering pass?


I render them all in one pass.

I tried PIX and nvision to profile but didnt got them working (some kind of runtime check error #0 where the stack pointer gets corrupted supposedly when I do a ID3D11Texture2D::GetDesc() call o.O dont know whats going on there, only happens when i try to start through the profiling tools...)
But thanks anyway.
 

When the GPU is taking longer than the CPU, Present will start to block once the CPU is a few frames ahead


Is there an easy way to find out if this is really the case?

I appreciate your help!

edit:

I'm kind of confused right now, so just for clearification:

when I perform a Draw() - call on an immediate context the execution will be performed immediate...

//...
context->Draw(...);
// Marker

So when the execution gets to the "Marker" the drawing should be finished and the possible results in the buffers ready.

 

If that is so the actual render time of my scene is like 10ms.

 

The question is now what is left to do at the Present() call that takes so long. "Presents a rendered image to the user." what could be found all over the documentation is kind of vague to me.



#5 Pink Horror   Members   -  Reputation: 865

Like
0Likes
Like

Posted 04 October 2013 - 08:08 PM


when I perform a Draw() - call on an immediate context the execution will be performed immediate...
//...
context->Draw(...);
// Marker
So when the execution gets to the "Marker" the drawing should be finished and the possible results in the buffers ready.

 

No, the other two people explained how it works. I believe immediate context means it is starting the command immediately, as opposed to adding them to a list of commands for you to execute later.

 

The huge difference between your near and far times should be all the proof you need to know it's waiting on drawing. Why else would distance affect the time?



#6 Wh0p   Members   -  Reputation: 177

Like
0Likes
Like

Posted 05 October 2013 - 04:44 AM


I believe immediate context means it is starting the command immediately, as opposed to adding them to a list of commands for you to execute later.

Hmm,.. you are right. But I can not help myself that somewhere I read that the GPU blocks the CPU execution till finished. Could that be Dispatch (). would make sense to me, because the CPU will most likely need the results.

 

Reducing light also helps the performance. Looks like I have to implement clustering :)



#7 MJP   Moderators   -  Reputation: 8746

Like
1Likes
Like

Posted 05 October 2013 - 12:38 PM

The only functions that can block the CPU are Map, Present, and Flush. All other functions cause commands to be generated in a command buffer that is consumed later by the GPU, which means they are asynchronous from the point of view of the CPU. Map will block when you're trying to read data on the CPU that was generated by the GPU, so that the GPU can catch up and the data will actually be in the buffer that you're mapping. Present will block when the CPU gets too far ahead of the GPU, as I explained already. The reason this happens in Present is because it's generally considered to be the "finishing point" of a frame, since you're taking everything the GPU rendered and showing it on screen. Flush will stall and wait for all pending commands to be executed by the GPU.

If you're looking to do GPU performance analysis, I would suggest using Nsight for Nvidia hardware and GPU PerfStudio for AMD hardware. Those programs can give you low-level timing and counter information for a particular Draw or Dispatch call.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS