Jump to content
  • Advertisement
Sign in to follow this  

Sorting Renderqueue

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

Hi, I know I have to sort asset in render queue like below. 1. Effect File > Video Buffer(VB>IB) > Texture 2. Effect File > Texture > Video Buffer But I'm not sure which one is the best in general. Or is there something I forget?

Share this post

Link to post
Share on other sites
The best completely depends on how your app uses its resources. If your app is shader heavy, the sort by shader. If your app is texture heavy, the sort by texture. The only way you can really find out what the best would be is by testing.

You can make your sort generic enough so that it would be easy to sort by different catagories and then see the change in performance. For example you can use a 2 byte ID for shaders, textures and VBs. Then

struct Object
uint16 shader;
uint16 texture;
uint16 buffer;
uint64 id;

// Sort objects based on Object.id;
Sort( vector_of_objects );

foreach( object o )

The above sorts based on shader->texture->vb. If you wanted to change teh sort order just change the order of the variables in the union.

also, give this thread a read.

Share this post

Link to post
Share on other sites
I see.
Then, I'm thinking how to group buffers to sort.
Probably make a name for the buffer first.
Because buffer have no name unlike texture and give a ID.
So if the same ID, I'll not change SetSourceStream() etc.
But what if the buffer's contents changed.
For example, when object animated
the buffer should be lock(), unlock() and the value will be changed.
In this case, same IDs but different buffers I guess.
Which means I need to SetSourceStream() again.
Of course this isn't what I want.

So I think for grouping the asset
it could be managed with reference count.
So create one buffer and give the buffer's pointer
if there is a buffer which has the same name.
I'm not sure about fixed pipeline, but In programmable pipeline
I think it can be possible.

This is what I thought until now... am I right?^^;
or give me some help.

Share this post

Link to post
Share on other sites
A method I've wanted to try for a while now involves a more graph like approach than actual sorting. I worked it through on paper a while back, but haven't had the time to try it properly.

Represent each of your Draw**() submissions by it's required pipeline configuration - which shaders, which constants, which textures, which streams/vb's etc... Now take these as the nodes/vertices in a graph. The edges between nodes represent the cost of changing from the source configuration to the destination configuration. Lower costs are better.

As an example, if the source state requires {VSa, PSb, Tex0, VB2} and the destination state just used different geometry: {VSa, PSb, Tex0, VB3} then the connecting edge would have a weight of "1". If it used a different pixel shader, texture and geometry then it'd have a weight of 3.

The problem with this approach is that you quickly get into the realm of graph theory and related complexities. In particular you'd probably need to use some sort of travelling salesman or Kruskal's MST algorithm. Not sure how runtime friendly such implementations would be, but possibly a good candidate for multi-core machines.

One advantage I did realise with this possible approach is that you can bias the weights based on the cost of the state changes (rough guide to costs). In my original example I used a cost of "1" for each/any state change - but things like a SetVertexDeclaration() call is much more expensive than a SetTexture() call.

You could then do some testing with the various weights - moving them up or down and seeing what the resultant performance is like. You could conceivably do it in real-time/dynamically as well - some sort of load-balancing maybe.

Maybe I'll get around to writing this idea up properly - anyone be interested in that?


Share this post

Link to post
Share on other sites
Sign in to follow this  

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