Built-in effects, permutations, and performance

re: Built-in effects, permutations, and performance

Shawn Hargreaves - MSFT — Mon, 10 May 2010 17:13:43 GMT

> Exactly, about 60 instances per draw call. And I want 10000+ :)

So, on platforms that support it, use true hardware instancing. On platforms that do not support hardware instancing, shader instancing is a great alternative.

Obviously if you want to draw more instances than fit into shader registers, you must split into multiple batches. That's still much faster than doing no instancing at all. Check out eg. our instancing sample, and you will see that shader instancing and hardware instancing are usually about the same speed in practice.

re: Built-in effects, permutations, and performance

Maurice Sibrandi — Mon, 10 May 2010 11:47:05 GMT

Exactly, about 60 instances per draw call. And I want 10000+ :)

re: Built-in effects, permutations, and performance

Shawn Hargreaves - MSFT — Fri, 07 May 2010 17:35:43 GMT

> Aren't you very limited in how many instances you can render here?

Yes, exactly the same as with any implementation of the shader instancing algorithm. From the doc that comes with our Instanced Model sample:

There is a limit on how many shader instances can be drawn in a single batch. This comes partly from the limited number of shader constant registers available to hold the instance transform matrices (see the comment and MAX_SHADER_MATRICES constant at the top of InstanceModel.fx) and partly from the limited range of 16-bit index values. If we repeated the model data too many times, our 16-bit indices would overflow. We do not want to use 32-bit indices because they are not universally supported on all graphics cards. The InstancedModelPart class stores the result of combining these two batch size limits in the maxInstances field. If asked to draw more copies than this limit, the DrawShaderInstancing method splits up the request, drawing as many instances as possible in each call to DrawIndexPrimitives.

re: Built-in effects, permutations, and performance

Maurice Sibrandi — Fri, 07 May 2010 14:40:48 GMT

> Exactly. Skinned character rendering and vertex shader instancing are exactly the same thing, just used to achieve a different goal, so the same shader can be used for both.

Aren't you very limited in how many instances you can render here? First of all the vertexbuffer needs all the vertexdata for all the instances, but most importantly the instance data has to be set using shaders constants which are limited in size (256?)

re: Built-in effects, permutations, and performance

Shawn Hargreaves - MSFT — Thu, 06 May 2010 21:21:55 GMT

> Just from thinking about it (not from any kind of documentation), I believe this would be the vertex shader instancing implementation.

Exactly. Skinned character rendering and vertex shader instancing are exactly the same thing, just used to achieve a different goal, so the same shader can be used for both.

It is quite trivial to change the shader instancing technique (from the instancing sample on creators.xna.com) to use SkinnedEffect as opposed to the custom shader it uses today.

re: Built-in effects, permutations, and performance

Justin Olbrantz (Quantam) — Thu, 06 May 2010 21:19:20 GMT

Re: "I need XNA 4.0. Fix the installer so it will install on Server 2008 (says it only supports Vista and Windows 7"

Never mind, I just realized the 4.0 CTP only includes phone. Hurry up and get the rest of it done, and make sure that installer works on Server 2008 :P

Though I do have the exact question Daniel asked: wouldn't the lack of lighting for DualTextureEffect and AlphaTestEffect be a significant disadvantage for some common use scenarios?

re: Built-in effects, permutations, and performance

Shawn Hargreaves - MSFT — Thu, 06 May 2010 21:19:02 GMT

> I was wondering why the dual texture effect doesnt support any lighting?

To support every possible permutation of N different shading options is an exponential permutation problem, requiring 2^N different shaders.

We had the resources to create around 50 different shaders, which would have given us room to support just log2(50) options, which is nowhere near enough to support a range of interesting rendering features.

Instead, we chose to pick and choose only the more useful combinations of features, so we could support a larger total set of features without having to create an exponential number of different shaders.

More info in this article: http://blogs.msdn.com/shawnhar/archive/2010/04/28/new-built-in-effects-in-xna-game-studio-4-0.aspx?CommentPosted=true#commentmessage

re: Built-in effects, permutations, and performance

Justin Olbrantz (Quantam) — Mon, 03 May 2010 19:31:01 GMT

"I would love to see that trick :)"

Just from thinking about it (not from any kind of documentation), I believe this would be the vertex shader instancing implementation. That is, each vertex has an associated instance index, and the vertex data is duplicated for each instance (see the instancing sample for more information). In this case, that instance index == the bone index.

However, this is relatively inefficient, as it requires the vertex list to contain duplicate vertices for ALL instances. The better method is to use hardware instancing where there's only one set of vertex data plus a separate set of instance indices. But I'm guessing SkinnedEffect doesn't support that, as it's a fundamentally different operation than skinning.

re: Built-in effects, permutations, and performance

Maurice Sibrandi — Mon, 03 May 2010 09:40:18 GMT

> Neat trick: you can use SkinnedEffect with WeightsPerVertex = 1 to implement shader based instancing.

I would love to see that trick :)

re: Built-in effects, permutations, and performance

DrXner — Mon, 03 May 2010 09:27:13 GMT

Congratulations on the wedding!