Jump to content

  • Log In with Google      Sign In   
  • Create Account


Direct3D 11 Present makes up 98% of FPS ?


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
5 replies to this topic

#1 StanIAm   Members   -  Reputation: 203

Like
0Likes
Like

Posted 24 October 2013 - 12:16 PM

Hey guys I have a problem in my renderer right now. I don't know why but I have a very slow fps rate when rendering a mesh.I loaded the sponza mesh with only 190k verts and have about 200 fps ( HD6970 and Eightcore CPU).. Well my profiler says me that the present function makes up 98% of the rendering. Stuff like Draw Index/Vertexbuffers, shader linkage and so one only take < 1 - 1 % ,but the present function 98%!! This isn't normal I think.

 

Can you help me with that why this is so ??



Sponsor:

#2 C0lumbo   Crossbones+   -  Reputation: 2203

Like
3Likes
Like

Posted 24 October 2013 - 12:35 PM

The present function will be doing nothing on the CPU, except waiting for the GPU to finish rendering your mesh. Your GPU is taking about 5ms to render it.

 

Once you add some work to the CPU (the game), you'll find that work is happening in parallel to the GPU, so you'll effectively get that 'present' time back.



#3 StanIAm   Members   -  Reputation: 203

Like
0Likes
Like

Posted 24 October 2013 - 12:40 PM

Okay but this is very slow isn't it ?? I have the cascade shadow demo from the smaple browser and have there about 400 fps with shadows and light, a very big scene and textures. And here is only a little mesh with 1 texture which takes so long ....



#4 kuroioranda   Members   -  Reputation: 304

Like
2Likes
Like

Posted 24 October 2013 - 01:46 PM

Okay but this is very slow isn't it ?? I have the cascade shadow demo from the smaple browser and have there about 400 fps with shadows and light, a very big scene and textures. And here is only a little mesh with 1 texture which takes so long ....

 

No, because it's proportional. If you are just issuing a call to render a single mesh, that is very, very fast. Present may be slower, but it only seems so expensive because it's it's slower than doing a very fast thing.

For a real world comparison, this is similar to saying that a donut at 50 cents is expensive because a stick of gum only costs 5 cents. The donut is not expensive, they gum is just insanely cheap.



#5 Matias Goldberg   Crossbones+   -  Reputation: 3146

Like
2Likes
Like

Posted 24 October 2013 - 07:43 PM

Measure in milliseconds, not in frames per second



#6 mhagain   Crossbones+   -  Reputation: 7823

Like
1Likes
Like

Posted 25 October 2013 - 03:59 PM

Another key mistake you're making here is measuring CPU time and assuming that those measurements are in any way whatsoever representative of what's going on on the GPU.  They're not.  Your various Set/Draw/etc commands don't actually do much at all - they just add a command and it's parameters to your driver's internal command buffer and will normally then return immediately.  Hence the fact that you're seeing them not taking much time on the CPU - that's a correct reading.  A Draw command (unless it needs to flush the buffer for any reason) will behave like this irrespective of how much geometry you're drawing.

 

If you want to profile GPU time then use a correct methodology for profiling GPU time; measuring CPU time is not the way to do it.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





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