<p>It depends on your GPU. "Tiled renderers" do this for you so the benefit of doing it yourself is minimal (unless you have some more efficient way of knowing the order, e.g. sorting a fixed-viewpoint scene in advance). In this case, your best way of keeping efficiency is by ensuring they are allowed to draw the scene all in one go by avoiding <code>glReadPixels</code> and similar sync points between draw calls.</p>

<p>Even for a truly immediate-mode renderer, instancing can be hugely powerful and reducing overdraw is unlikely to be worth it, but the trade-off comes down to whether you're bottlenecked on the fragment shader or by the memory bandwidth used feeding vertices to the vertex shader. In turn that will depend on how big your instanced geometry is (and how many instances), and how long your fragment shader takes to execute. These are all specific to your application and to the GPU you're running on, so you can only really know by profiling.</p>

<p>As an outright guess I'd say it's unlikely that the change you're suggesting will improve performance, unless you have few instances and a big fragment shader on a non-tiled GPU architecture.</p>

CC BY-SA 4.0
2019-08-30T16:51:51.057Z
2019-08-30T16:51:51.057Z
Dan Hulme
<p>I've been doing some searching online and it seems like I could improve my renderer by ordering my draw calls based on depth. For opaque objects render the closest items first and move backward in depth to hopefully take advantage of depth test rejection.</p>

<p>The question I have is would this be worth the tradeoff of sacrificing instancing? It seems like the most straightforward approach would be to stop instancing completely and do each draw call one by one. I'm sure you could write some clever code to find groups within a new depth-first rendering order to instance but it seems like you'd get substantially less benefit.</p>

<opengl><directx11><optimisation><scene-graph>
Trading off instancing for render order
JHall
# Trading off instancing for render order

(Asked by: username_0 on 2019-08-30)

I've been doing some searching online and it seems like I could improve my renderer by ordering my draw calls based on depth. For opaque objects render the closest items first and move backward in depth to hopefully take advantage of depth test rejection.

The question I have is would this be worth the tradeoff of sacrificing instancing? It seems like the most straightforward approach would be to stop instancing completely and do each draw call one by one. I'm sure you could write some clever code to find groups within a new depth-first rendering order to instance but it seems like you'd get substantially less benefit.

**Tags:** opengl, directx11, optimisation, scene-graph


---

## 1 answers

### Answer by username_1 on 2019-08-30. Score: 4 | Accepted answer

It depends on your GPU. "Tiled renderers" do this for you so the benefit of doing it yourself is minimal (unless you have some more efficient way of knowing the order, e.g. sorting a fixed-viewpoint scene in advance). In this case, your best way of keeping efficiency is by ensuring they are allowed to draw the scene all in one go by avoiding `glReadPixels` and similar sync points between draw calls.

Even for a truly immediate-mode renderer, instancing can be hugely powerful and reducing overdraw is unlikely to be worth it, but the trade-off comes down to whether you're bottlenecked on the fragment shader or by the memory bandwidth used feeding vertices to the vertex shader. In turn that will depend on how big your instanced geometry is (and how many instances), and how long your fragment shader takes to execute. These are all specific to your application and to the GPU you're running on, so you can only really know by profiling.

As an outright guess I'd say it's unlikely that the change you're suggesting will improve performance, unless you have few instances and a big fragment shader on a non-tiled GPU architecture.


---

