Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Sorting shaders

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

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.

Share this post

Link to post
Share on other sites
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]

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites

  • 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!