Is drawing front-to-back necessary for optimizing renders?

Question

I\'ve seen the occasional article suggest ordering your vertices from nearest to furthest from the camera when sending them to OpenGL (for any of the OpenGL variants). The reaso

Answer 1

You are confusing a few concepts here. There is no need to re-order vertices (*). But you should draw objects that are opaque front to back. This enables what is called "early z rejection" on the GPU. If the GPU knows that a pixel is not going to be shaded by the z test it does not have to run the shader, do texture fetches etc.. This applies to objects in draw calls though, not to individual objects.

A simple example: You have a player character and a sky background. If you draw the player first, the GPU will never have to do the texture lookups for the pixels where the player is. If you do it the other way around, you first draw all the sky and then cover it up.

Transparent geometry needs to draw back to front of course.

( * )=vertices can be re-ordered for better performance. But doing early z is much more important and done per object.

Answer 2

Once a primitive is rasterized, its z value can be used to do an "early z kill", which skips running the fragment shader. That's the main reason to render front-to-back. Tip: When you have transparent (alpha textured) polygons, you must render back-to-front.

The OpenGL spec defines a state machine and does not specify in what order the rendering actually happens, only that the results should be correct (within certain tolerances).

Edit for clarity: What I'm trying to say above is that the hardware can do whatever it wants, as long as the primitives appear to have been processed in order

However, most GPUs are streaming processors and their OpenGL drivers do not "batch up" geometry, except perhaps for performance reasons (minimum DMA size, etc). If you feed in polygon A followed by polygon B, then they are fed into the pipeline one after the other and are processed independently (for the most part) of each other. If there are a sufficient number of polys between A and B, then there's a good chance A completes before B, and if B was behind A, its fragments will be discarded via "early z kill".

Edit for clarity: What I'm trying to say above is that since hw does not "batch up" geometry, it cannot do the front-to-back ordering automatically.