Jump to content
  • Advertisement
Sign in to follow this  
sipickles

Batching draw calls - worth it and how?

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

Hi, Much research I've read talks about batching calls of similar game objects to increase performance. This works by reducing the number of effect, texture switches (ie CPU->GPU traffic). This research was a few years old now. Is this advice still relevant? If so, what is the method that works for people? I have formulated a system where objects are added to a renderQ, which sorts based on Effect, Mesh then Texture. The renderQ then controls all the resource changes on the GPU and renders the objects in the Queue. Exceptions are allowed of course, but most objects are batched this way. Worth it?

Share this post


Link to post
Share on other sites
Advertisement
It depends if you want to get maximum performance from your card or will be satisfied with much less objects/effects in scene. So, it`s still relevant and will be. The API overhead is getting lower with each new revision, but it`s still significant. Maybe it`s lower with DX10, but framkly, who can afford making DX10-only game ?

Share this post


Link to post
Share on other sites
Quote:
Original post by sipickles
If so, what is the method that works for people? I have formulated a system where objects are added to a renderQ, which sorts based on Effect, Mesh then Texture.

The renderQ then controls all the resource changes on the GPU and renders the objects in the Queue.

Exceptions are allowed of course, but most objects are batched this way.

Worth it?

Absolutely worth it, and that's pretty much how you'd do it :)

Share this post


Link to post
Share on other sites
What about if the objects use transparency?

Don't they need to be rendered back-to-front?

I guess I can have a separate queue for these, which is sorted by distance, then effect, then mesh, then texture....

Share this post


Link to post
Share on other sites
Quote:
Original post by sipickles
What about if the objects use transparency?

Don't they need to be rendered back-to-front?


Given the usual blending modes, yeah.

Oh, and if you're interested in whether your sorting has an effect... why not just turn it off, and see what happens? :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Oh, and if you're interested in whether your sorting has an effect... why not just turn it off, and see what happens? :)


True. It was more of a 'to-implement or not-to-implement' question :)

Share this post


Link to post
Share on other sites
Quote:
Original post by sipickles
I have formulated a system where objects are added to a renderQ, which sorts based on Effect, Mesh then Texture.
The renderQ then controls all the resource changes on the GPU and renders the objects in the Queue.
Exceptions are allowed of course, but most objects are batched this way.

Worth it?


That's how I do it. Each graphic entities stores a few "renderables" (which are structures containing ids of vb, ib, texture, number of primitives, etc.) and during rendering, I send those structures to a Renderer which then sort everything and render each structure, taking care of resource/state changes, shaders, etc.

I like this approach because the Renderer has a view over the whole scene. You can create as many queue in your renderer (one for shaded entities, one for transparent entities, etc.) You can implement various sort function to see their effect on performance. You have complete control over state/resource changes. Etc.

And it has no impact on other part of the program. You can choose to have a scenegraph, an octree, a simple list of object, anything. In the end, it's just your Renderer sorting and drawing a bunch of simple structures in the best possible way :)

Share this post


Link to post
Share on other sites
Don't forget about instancing too, especially if you're working with D3D9. Draw calls can be very expensive, and batching together a bunch of small objects into one draw call will pretty much always be cheaper than drawing them individually.

Share this post


Link to post
Share on other sites
Quote:
Original post by paic
That's how I do it. Each graphic entities stores a few "renderables" (which are structures containing ids of vb, ib, texture, number of primitives, etc.) and during rendering, I send those structures to a Renderer which then sort everything and render each structure, taking care of resource/state changes, shaders, etc.
I hope you're not really meaning that each object needs to change IBO/VBO.

Share this post


Link to post
Share on other sites
Quote:
Original post by Krohm
I hope you're not really meaning that each object needs to change IBO/VBO.


Each "object" does nothing by itself. Each object simply contains ids of resources and informations needed to be drawn.

At render time, I simply have a bunch of structures. I could do absolutely everything from here : batch all small entities into a few big buffers, seperate transparent entities into another render queue to be depth sorted, sort the entities in a way that would minimize state changes, etc.

I hope you're reasured :)

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!