You all remember Material/Shader implmentation thread. Now this is a question for those who tried to build a shader system like that. I have most of it working except 2 things. One is VRAM caching (I will work on that later) and sorting shaders. Now this is somethin I can''t get to work right. I have one shader that draws GC using user selected blending. Then I have another effect that uses this shader (bounced GCs to it) to perform something like

final_color = ( A + B ) * C + D + E
 

Now A,B,C,D,E are instances of the same shader but with different blending functions. Now I need to generate some kind of "shader IDs" for them so my renderer can sort them to minimize state switching. Any idea how to do this. So far I only had one. The shader that requests bouncing also gives them some kind of "order-shift" to add to their default shader IDs. This works in some cases but totaly fails on others. You should never let your fears become the boundaries of your dreams.

Quick answer: The only fixed sorting order is given by the "hard" Shader ID (ie. same instances of one shader will get the same ID), and render target surface ID.

Each shader has a comparison callback function, which classifies two GCs based on local sorting properties and priorities. When sorting the final list in the render scheduler, you basically sort along those keys (in order of importance):

1) key 1 (fixed): target surface ID
2) key 2 (fixed): Shader ID
3) key 3 (dynamic): call comparison callback on the shader, in order to get the local sorting order between both GCs.

The comparison callback in a shader is free to return the order it seems fit, and will depend on its implementation. It can internally use as many keys as it wants, it only needs to return the final order of both elements (-1, 0, or +1 for smaller, equal, or greater respectively).

For example, if a shader renders a diffuse texture, with a constant colour, you'd have two states to minimize: the texture ID, and the constant colour. It's going to be faster to change the colour than the texture, so the later one should have higher priority. You'd get a final sorting order:

* key 1 (fixed): target surface ID* key 2 (fixed): Shader ID* key 3 (callback on diffuse/constant shader):   * key 3a: diffuse texture ID   * key 3b: constant colour  

The last combined key3 will change depending on the shader ID of the compared GCs. Both are guaranteed to have the same Shader ID, since it sorting key (key 2) always supersedes the callback key (3).


[edited by - Yann L on November 6, 2003 7:59:41 AM]

At least I know I''m on the right track. I have a system very simmilar to this. The difference it that I group all keys into one. Well, I''ll just have to try a bit harder to make this work as it should.

You should never let your fears become the boundaries of your dreams.