Jump to content
  • Advertisement
Sign in to follow this  
choffstein

OpenGL What is batching?

This topic is 4766 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

I have heard the term batching several times before, and was wondering what it was (and how it can be applied in OpenGL -- though, I don't want this post to be OpenGL specific). From the very little I have found (at last, I found a topic that google let me down on!), I think it has something to do with organizing the rendering of your geometry to make as few changes as you possibly can. So, for an example, I thought a simple 2d tile engine would make sense. I personally would rendering it with a triangle list (maybe quad list?). Each quad would have its own texture (hence the tile engine). Does it make sense to sort the quads by their texture, and use GL_QUADS for each group? Please, help a confused nubblet. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
I am not sure that what you describe is necessarily batching. However sorting geometry to minimize the number of opengl state changes is definitely a good thing to do for any moderately complex scene, I think.

I was under the impression that batching meant sending a bunch of polygons at the same time to the hardware (or at least the opengl layer) in order to maximize the throughput to the vertex pipelines.

Please correct me as I want to know this as well.

Rob

Share this post


Link to post
Share on other sites
Good batching means to take advantage of as much coherence in your scene as possible, mainly in order to reduce CPU overhead.

You can look at each render state as a bunch of sort keys. The first question is which key do you sort your scene by?

object #1 :
Render target : A
blending mode : K
z enable : true

object #2 :
Render target : A
blending mode : K
z enable : false

object #3 :
Render target : B
blending mode : K
z enable : true

object #4 :
Render target : B
blending mode : K
z enable : true

etc.

Objects 3 & 4 have the same render states, so they can be drawn one after another without changing state in between, or they could even be drawn in one draw call in some cases ( like if they were both in world space ).

It is easy to worry too much about this, but I have found that thinking about it a bit when you start your engine can help in the long run.

Many games still draw small pieces of geometry in separate calls. It is preferable for things like clumps of grass or rocks, or maybe even buildings in an RTS, to put them all in a big dynamic vertex buffer and draw them all at once.

For my particle system, I group all particles that were created together ( like from an explosion ), as one object. I cull or draw all of them in one call. That is an example of good batching. Poor batching would be to draw each particle one at a time.

This is more of an issue in DirectX, but it still can help in OGL as well.

Share this post


Link to post
Share on other sites
Quote:
I cull or draw all of them in one call.


What? You mean like instancing? I thought OpenGL didn't do that...

Share this post


Link to post
Share on other sites
In DirectX (you said you did not want this thread to be OpenGL specific) a batch is typically a single DrawPrimitives or DrawIndexedPrimitives (DrawXXX etc..) call. The more of these calls you make the more likely you are to be CPU bound. So batching in this context is not just reducing state changes, but rendering as much of your geometry as possible in a single call. A single call implies that the states must be the same for all the geometry in the call. There are a number of techinques and tricks for increasing batch size -- many of them the same as the techinques for decreasing state changes, save that even one cheep state change will split your batch.

Instancing, as an example technique, seems to be directly targeted at increasing batch size. Texture packing is another technique that applies to batching and perhaps to your 2d problem. To pack your textures you combine your textures into one and then adjust your texcoords so that each geometry uses only portion of the combined texture. This should allow you to draw a number of objects, with different textures, in one call.

The last paper I read from ATI said that a 1GHz box would be CPU bound with 25,000 batches a second (DirectX). I don't know how all this applies to opengl, but I have heard that it is not nearly as important.

Share this post


Link to post
Share on other sites
Typically you only really need to worry about expensive state changes - which boils down to texture binds and shader binds. Other state tends to be much more trivial to change, and you should instead worry about grouping individual polys into chunks o geometry to render at that point.

If you've got some really expensive shaders a rough front-to-back z sort can be good too.

Share this post


Link to post
Share on other sites
Quote:
The last paper I read from ATI said that a 1GHz box would be CPU bound with 25,000 batches a second (DirectX). I don't know how all this applies to opengl, but I have heard that it is not nearly as important.

here im getting ~10 million batches sec with opengl (athln64 2.0ghz gffx5900)

Share this post


Link to post
Share on other sites
I'll give an example where grouping by render state was more helpful that just reducing draw calls.

In my engine, I created per-caster shadow maps, so each shadow caster had its own 64x64 shadow map. I would render to it, then draw the floor using this texture, then do the next character, etc.

It was way too slow - like 80 fps with only one light and a couple of characters.

I changed it so that all characters allocated a 64x64 chunk on a 256x256 shadow map instead, drew all characters into this map, changing some shader constants and the viewport in between, then drew the receiver geometry with each sub-texture in turn.

This brought me up to ~200 fps. So, I still made the same # of draw calls, but I was able to avoid switching render targets, so it was a huge win.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!