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?

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{  union  {    struct    {        uint16 shader;      uint16 texture;      uint16 buffer;    };    uint64 id;  };};// Sort objects based on Object.id;Sort( vector_of_objects );foreach( object o ){  o->setShader();  o->setTexture();  o->uploadBuffer();  o->render();}

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.

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.

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?

hth
Jack

yep