I'm beginning to add shader based capabilities to my wrapper API for dx9.0c.

at first, i can get away with shaders for special effects (instancing, swaying grass, etc), and fixed function for the things its capable of (gourard and phong, alphatest and alpha blend, 2 stage texture blending, etc).

but if i eventually go to 100% shader based, this would likely call for a re-design of the render queue.

in fixed function, textures have the highest binding cost. so my render queue sorts on texture. to date that has been fast enough that i don't even bother with sorting on mesh, distance, etc. but that's just with placeholder graphics.

so looking forward to a time when i'm 100% shader based, what are the binding costs i'm looking at? where does setting vertex and pixel shaders and constants fall in the list of binding texture, input streams, shader constants, input formats, pixel shader, vertex shader, etc ? materials will be replaced by pixel shaders (right?) - so no binding costs there.

i'll want single purpose pre-compiled shaders, and i'll want to treat them as a shared graphics resource, in a memory pool, with state management, right? perhaps with shared memory pools of constants and formats as well?

D3D9 effectively has to validate the pipeline state before anything affecting the drawing is changed. Shaders are relatively expensive to validate, as the driver does internal microcode compilation and optimization before running the shader code, and checks that the input (and output) streams make sense against the shaders.

A good practice would be to sort the state changes by shaders, textures and vertex input streams.

Some D3D9 cards are limited on the available shader instruction count and performance, so you need to find a balance between the actual drawing performance and the batching performance. On more modern cards (D3D10 and up) it is much more feasible to define so-called "über-shaders" that don't need to be changed very often.

Overall, I'd sort by render target, then opaque/alpha test/alpha blend, then coarse depth sorting (very rough front to back - maybe a dozen to a few hundred buckets), then shader and render state, then by resources, then by constants.

Is this specific to DX9? Most people seem to suggest to sort by shader before depth, at least from what I've seen.

sort the state changes by shaders, textures and vertex input streams.

vertex and pixel shader binding costs are similar?

i suspected shader binding would be expensive.

and conditional branching in uber shaders can be less costly than two smaller single effect shaders?

so i'd want to do something like bind the standard transform vertex shader, then do passes for each pixel shader effect, such as mip mapped, alpha test, alpha blend, 2 stage tex blend, and non-mip mapped (if i even use that) ?

and on each pixel shader pass, i draw in texture, mesh, near to far order, right ?

or write one or more uber shaders that combine two or more passes?

On more modern cards (D3D10 and up) it is much more feasible to define so-called "über-shaders" that don't need to be changed very often.

while i'm using dx9. odds are the game will require at least a dx10 capable card. but i'm still limited to version 3 shader code and the limitations on number of constants.

, I'd sort by render target,

fortunately, i never change render target. : )

then opaque/alpha test/alpha blend,

as one uber pixel shader, or three separate shaders? one uber, right? the tests are similar. are the inputs the same? i forget, is there alpha data in an opaque texture? r8g8b8a8, yeah i guess there is, so inputs for all three effects would include alpha, so same API (inputs/params) for all three effects in one uber shader? what is that? x y z from the vertex shader, and r g b and a from the texture? oh - and lite direction and intensity as constants... god its been forever since i did graphics code!

it looking like for something like caveman, i'd have a standard transform vertex shader, and a wind effects vertex shader. and i'd have opaque, alphatest, alphablend, and 2 stage tex blend as pixel shaders. just six in all?

what about mip-mapped vs non-mip-mapped? different pixel shader code for each version, right? i use both mipmaped and non-mipmapped textures.

L. Spiro talked about it back in 2011.

The thing is, I don't know how out of date it is. How DX9 abstracts the HW is very distant from how modern GPUs works nowadays.

The question is "are you supporting DX9 to support Win XP and run in modern GPUs? or are you supporting DX9 to support old cards while you use DX11+ to run in modern GPUs?"

Because the answer to the sorting problem can vary based on how you answer this question. Older cards have a higher penalty for swapping textures than modern cards do, for example. In newer cards, changing the vertex format means the driver will internally swap a different shader.

Everyone agrees RenderTarget comes first, and that changing uniforms is cheap. But are textures more expensive than swapping shaders or changing vertex formats? Mmm... good question.

On top of this, there's a lot of CPU-side validation going on.

The best answer I can give is "just try it". Run your system on the target GPUs you want to support and swap different rendering orders to see which one performs best on your general case.

But are textures more expensive than swapping shaders or changing vertex formats? Mmm... good question.

e.g. perhaps swapping textures takes less CPU time than swapping shaders... but perhaps swapping shaders has a bigger impact on the GPU frametime!

Is this specific to DX9? Most people seem to suggest to sort by shader before depth, at least from what I've seen.

Sorting by coarse front-to-back depth doesn't help your CPU time at all -- it probably hurts it by requiring more state changes overall... but can help on the GPU by getting more overdraw to be rejected by early-Z testing. If your sorting is too fine grained, then you'll start to hurt the GPU by excessive shader swapping / state changes, which means the GPU may have to stall between successive draws in order to reconfigure itself. If your sorting is too coarse, then you don't actually stop any overdraw from occurring.

e.g. if you sort by shader, and then by depth within each shader-grouping, it's possible that you don't stop any overdraw. Perhaps shader-A is used on the background and shader-B is used on the foreground. Sorting by shader means you draw A first and then B, which means you're drawing background before foreground. Doing a very coarse depth sort before sorting by shader is a trade-off to make sure that you get decent value out of early-Z testing.