Jump to content
  • Advertisement
Sign in to follow this  
sdaq

93.58% of Batches have only a single vertex !?!

This topic is 2478 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hello world,

gDEBugger Statistics and Redundant Function Calls Viewer reported to me that 93.58% of my batches have 1 vertex. I'm using OpenSceneGraph and I don't feel like diving into the OSG renderer source and rebuilding... Is there an easy way for gDEBugger to tell me what effect is causing this? E.g. can I just break on the draw that only has 1 vertex and look at the shader it is using? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
update: just by chance I decided to go throught the code and comment out every instance of glBegin/glEnd and sure enough that was enough to cease submitting batches of a single vertex. Despite the catch, my framerate has not improved! oh well...

Share this post


Link to post
Share on other sites

update: just by chance I decided to go throught the code and comment out every instance of glBegin/glEnd and sure enough that was enough to cease submitting batches of a single vertex. Despite the catch, my framerate has not improved! oh well...


Yes, glBegin / glEnd is used for immediate mode which sends a single vertex at the time, (using the glVertex calls), it is deprecated for a reason.

Framerate is a very poor way to measure render speed and in most cases your framerate will be capped by the monitors refreshrate (60hz is normal these days), it can also be limited by the CPU. its better to measure the time it takes to:
1) update the gamestate
2) execute all render calls.
3) total time spent per frame.

Share this post


Link to post
Share on other sites
I imagined that removing 93.58% of the batches would amount to a nominal improvement in framerate, but is it possible for 93.58% of the batches to run in only 10% of the total time to execute all render calls?

Share this post


Link to post
Share on other sites

I imagined that removing 93.58% of the batches would amount to a nominal improvement in framerate, but is it possible for 93.58% of the batches to run in only 10% of the total time to execute all render calls?


No , but if you are measuring framerate then you aren't measuring the time it takes to execute the render calls, a render call to draw 50 trillion triangles take the same amount of time as a render call to render 1 triangle, the render calls are processed entierly on the CPU while the actual rendering is done in parallell by the GPU, when you swap the buffers, attempt to read from the backbuffer or call glFinish() your program will stall and wait for the GPU to finish its part of the job.

Reducing the amount of work done on the CPU side of things will not improve performance if your main bottleneck is on the GPU side.

Share this post


Link to post
Share on other sites
i'm confused now. I get that draws will take the same amount of time regardless of how many primitives there are. but are you are saying that reducing the number of batches only reduces the amount of work done on the CPU side? how is it possible that the GPU works the same amount to execute 5000 batches with one vertex as 1 batch of 5000 verts?

Share this post


Link to post
Share on other sites

i'm confused now. I get that draws will take the same amount of time regardless of how many primitives there are. but are you are saying that reducing the number of batches only reduces the amount of work done on the CPU side? how is it possible that the GPU works the same amount to execute 5000 batches with one vertex as 1 batch of 5000 verts?


Because if you don't change state between the batches then the driver can treat multiple batches as one big batch for you and the GPU operates on vertices and pixels/fragments, not batches/meshes/etc.

Share this post


Link to post
Share on other sites
okay... then the benefit of batching is only reducing calls on the CPU side? there is no benefit on the GPU side?

Share this post


Link to post
Share on other sites
When you say 98% of calls, how many calls are you talking about? I have been able to do hundreds of thousands of calls very very fast. If your program is running super fast and you eliminate some glBegin/End calls, then your program is still super fast, so you have to look at real statistics.

how is it possible that the GPU works the same amount to execute 5000 batches with one vertex as 1 batch of 5000 verts?[/quote]
It doesn't. I batch of 5000 verts is way faster than 5000 batches of 1 vertex. 5000 batches isn't that much though, so if you were at a huge FPS, then removing 5000 or adding 5000 batches is not going to do that much.

So if you have 5000 vertices in a VBO and call draw, you took 1 draw call. Say a draw call takes 1 second to get to the GPU. And you can draw 5,000 vertices a second.
Then your time is wait 1 second for draw call, then spend 1 second to draw = 2 seconds

If you have 1 vertex, and call draw 5,000 times, you have 5,000*1 second = 5,000 seconds just to send those draw commands to the GPU.

Share this post


Link to post
Share on other sites

I batch of 5000 verts is way faster than 5000 batches of 1 vertex.


I agree, but SimonForsman seems to be saying that batching only helps the CPU and does not help the GPU.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!