Jump to content
  • Advertisement
Sign in to follow this  
MegaPixel

I've got an Idea, is it feasible ? loads of InputLayout and a vertex shader with a big input struct

This topic is 2480 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 all,

I was thinking about this for a while.

Is it possible to create just one vertex shader with a big input vertex struct and selectively activate a subset of semantics varying just the input layout ? And also, does that make sense and is convenient in general?

The D3D11 CreateInputLayout function doesn't prevent to do this, except that it will launch you a warning, but that warning is not blocking.

From the remarks:

If a data type in the input-layout declaration does not match the data type in a shader-input signature, CreateInputLayout will generate a warning during compilation. The warning is simply to call attention to the fact that the data may be reinterpreted when read from a register. You may either disregard this warning (if reinterpretation is intentional) or make the data types match in both declarations to eliminate the warning.

Now I have two quetions:

1) If that is theoretically possible, will my vertex input data be interpreted correctly from the Input Assembler ?
2) If yes, will this approach be efficent ? I mean normally I've always heard that people tend to keep the input struct for a vertex shader as small as possible to limit the vertex shader input size.

If both the two questions will be satisfied it would be possible to keep one shader and more input layouts that selectively will activate the semantics in the vshader input struct .... !

What do you guys think about this ?

Thanks in advance for any reply

Share this post


Link to post
Share on other sites
Advertisement
That's one of the two common ways you can solve the problem of shader permutations. If each bit of data comes from different streams, you can avoid having to send data you don't need in the shader. In the shader itself you can use a multiplier to control if the input gets applied to the output, something like this:

outputColor = 0;
outputColor += vertexColor * applyVertColor;
outputColor += textureColor * applyTexColor;


If the model uses vertex color, applyVertColor will be 1, otherwise it will be 0 and the outputColor doesn't get affected by it.

An alternative is creating a complicated shader permutation management system, in which you have a bunch of defines in the shader and a bitfield to represent each thing you can turn on and off.

Share this post


Link to post
Share on other sites

That's one of the two common ways you can solve the problem of shader permutations. If each bit of data comes from different streams, you can avoid having to send data you don't need in the shader. In the shader itself you can use a multiplier to control if the input gets applied to the output, something like this:

outputColor = 0;
outputColor += vertexColor * applyVertColor;
outputColor += textureColor * applyTexColor;


If the model uses vertex color, applyVertColor will be 1, otherwise it will be 0 and the outputColor doesn't get affected by it.

An alternative is creating a complicated shader permutation management system, in which you have a bunch of defines in the shader and a bitfield to represent each thing you can turn on and off.


mmm, so my idea to create different input layout keeping the shader input struct big is correct ? ...

Share this post


Link to post
Share on other sites

[quote name='turch' timestamp='1330699140' post='4918603']
That's one of the two common ways you can solve the problem of shader permutations. If each bit of data comes from different streams, you can avoid having to send data you don't need in the shader. In the shader itself you can use a multiplier to control if the input gets applied to the output, something like this:

outputColor = 0;
outputColor += vertexColor * applyVertColor;
outputColor += textureColor * applyTexColor;


If the model uses vertex color, applyVertColor will be 1, otherwise it will be 0 and the outputColor doesn't get affected by it.

An alternative is creating a complicated shader permutation management system, in which you have a bunch of defines in the shader and a bitfield to represent each thing you can turn on and off.


mmm, so my idea to create different input layout keeping the shader input struct big is correct ? ...
[/quote]

just one side note: I see the advantage of your method, but I can't understand how is related (and if is related) to my two questions in my first post ...

Share this post


Link to post
Share on other sites

Is it possible to create just one vertex shader with a big input vertex struct and selectively activate a subset of semantics varying just the input layout ? And also, does that make sense and is convenient in general?


Yes, what activates or deactivates the inputs is the additional parameter which I described earlier. If the input vertex doesn't have vertex color for example, the registers that store that data can have any random trash, and it won't matter because it gets multiplied by 0.


1) If that is theoretically possible, will my vertex input data be interpreted correctly from the Input Assembler ?


I haven't used dx 11 very much, but the dx 9 equivalent would just leave trash data in the input registers. Since this data isn't used, it doesn't work out to be a problem.


2) If yes, will this approach be efficent ? I mean normally I've always heard that people tend to keep the input struct for a vertex shader as small as possible to limit the vertex shader input size.


If you use streams, you don't have to pass in any inputs that aren't used. You avoid costly ifs in the shader by using a multiplier. You still have to calculate everything in the shader regardless of whether it is used or not, but you save on shader switching and sorting based on shader. So the net effect is lowering cpu usage and increasing gpu usage (specifically, the vertex shader stage, which in many cases is not the bottleneck).

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!