StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Altering shader parameters will be just as slow. Ideally you want to write a Shader 2 based shader that uploads a large section of the attribute buffer to the graphics card. You then have a per-vertex attribute field which can select the appropriate attribute buffer.</p> <p>Your performance problems will come from the number of draw calls you use. The more draw calls you use the more performance suffers. Any change of shader constants or texture will require a new DIP call. What you want to do is minimise the number of shader constant modificatiosn AND the number of DIP calls. </p> <p>It becomes quite an involved process mind. </p> <p>For example if you are processing a skeletal model with 64 bones in it then you have 2 options. 1 you set the world matrix for each bone's mesh data and call DIP. OR you load as many of the bone matrices as you can in one go and use a value on the vertex to select which bone it will use and call DIP once. The second WILL be faster. You will probably find you can do some multi-bone based skinning quite easily this way as well.</p> <p>This goes for anything that causes a shader constant change. Do note that, even though you may use the fixed function pipeline, most modern graphics hardware (ie anything since the Radeon 9700 released in 2002) will translate Fixed function to shader based so the same performance issues apply. </p> <p>Basically the thing to avoid over anything is anything that causes you to make another DIP call. Obviously its impractical to avoid doing this for everything and certain changes are less costly. As a rough rule of thumb the things to avoid, in order of expense, are as follows: (Be warned its been a while since i tested this so you may want to do some testing and alternative reading on the subject)</p> <p>1) Change Shader<br> 2) Change Texture<br> 3) Change Shader constant<br> 4) Change Vertex Buffer<br> 5) Change Index Buffer<br></p> <p>1 is by far the most expensive.</p> <p>4 and 5 are pretty cheap by comparison to the rest but a different vertex format will likely cause bigger problems as it may cause the shader to get changed.</p> <p>Edit: I'm not entirely sure why changing constants hurts so much. I would have thought such changes would pipeline well. Maybe on moden hardware its not such a problem. On some early hardware the constants were compiled into the shader so changing constants resulted in a full shader change.</p> <p>As with anything you are best off trying and see what happens. </p> <p>An interesting solution for sorting all your calls can be to use a sort key where the top 8 bits give you a shader id. The next 10 bits for texture and so on. You then perform a normal numeric sort and you have an easy way of playing with different sort orders to see what gives best performance :) </p> <p>Edit2: Its worth noting that anything that changes the pixel shader state is more costly than changing the vertex buffer state because it is deeper in the pipeline. Thus it takes longer for it to bubble through ...</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload