   Shader costants speed access.
  I have a question regarding shaders to the experts here. :DI was wondering...there is difference in speed between accessing to constant buffers (costants in DX9) and accessing to vertex/pixel data (the data passed to the VS/PS functions)?If yes, why?Because i've tried with a simple shader with a constant buffer with a color value, and the same shader, but with the same color value passed inside the vertex data. The second implementation was quite faster...[Edited by - feal87 on May 26, 2009 2:08:44 PM]
  Well it's going to depend on the specific hardware, but in generally you'll probably find that there are different access speeds with constants and interpolants.  Constants have to be placed in memory that's accessible by multiple shaders, interpolants do not.   ;  Another thing....i have a simple shader with this as Vertex Shader.VS_OUTPUT VS( VS_INPUT input ){    VS_OUTPUT output = (VS_OUTPUT)0;#ifdef DX9matrix world = World;world[3].x = world[3].x+0.5;world[3].y = world[3].y+0.5;world = mul(world, ViewProjection);output.Pos = mul( float4(input.Pos,1), world);#elsematrix world = World;world = mul(world, ViewProjection);output.Pos = mul( float4(input.Pos,1), world);#endif    output.Tex = input.Tex;    return output;}Why if i build over DX9 (Shader Model 3.0) the compiler generate the preshader (for the first mul and the +0.5) while over DX10 it does not generate any preshader (ruining the performance for quite a bit...)?The two shader are build with OptimizationLevel3 as only flag...   ;Quote:Why if i build over DX9 (Shader Model 3.0) the compiler generate the preshader (for the first mul and the +0.5) while over DX10 it does not generate any preshader (ruining the performance for quite a bit...)?sm 4.0 + no longer has a preshader concept.  You may as well just do this simple one off math calculation on the CPU anyway.  Preshaders do provide a benefit when compared to running the matrix mult for each vertex, but neither are the preferred approach. Keep in mind that you get the most bang out of hardware when it can run a huge number of things in parallel -- and any single or serial calculation is really just preventing you from really taking advantage of what the GPU can provide.  Where as your CPU can use the SSE unit to provide single calculations in very reasonable time, and this approach makes it clear that the data you are calculating only needs to be done once for the entire draw call.*Edited for accuracy.*[Edited by - DieterVW on May 27, 2009 3:32:16 PM];Quote:Original post by DieterVWQuote:Why if i build over DX9 (Shader Model 3.0) the compiler generate the preshader (for the first mul and the +0.5) while over DX10 it does not generate any preshader (ruining the performance for quite a bit...)?sm 4.0 + no longer has a preshader concept.  You may as well just do this simple one off math calculation on the CPU anyway.  It's not efficient to give the hardware a preshader since an entire warp would have to execute it, and of course it stalls the real shader from running while the preshader does it's thing.  Preshaders do provide a benefit when compared to running the matrix mult for each vertex, but neither are the preferred approach. Keep in mind that you get the most bang out of hardware when it can run a huge number of things in parallel -- and any single or serial calculation is really just preventing you from really taking advantage of what the GPU can provide.  Where as your CPU can use the SSE unit to provide single calculations in very reasonable time, and this approach makes it clear that the data you are calculating only needs to be done once for the entire draw call.Thanks for your answer, this is what i was searching for. I'll switch to make those calculation on the CPU and pass the shader the already calculated values. :);Quote:Original post by DieterVWQuote:Why if i build over DX9 (Shader Model 3.0) the compiler generate the preshader (for the first mul and the +0.5) while over DX10 it does not generate any preshader (ruining the performance for quite a bit...)?sm 4.0 + no longer has a preshader concept.  You may as well just do this simple one off math calculation on the CPU anyway. Are you sure about this?  I don't use DX10 very much, but I can't find any references anywhere to preshader functionality being removed.  In fact the effect compiling functions still have the "NO_PRESHADER" flag listed in the documentation.Also the rationale for removing them doesn't really make sense, since preshaders are executed on the CPU and not on the GPU.;Quote:Original post by MJPQuote:Original post by DieterVWQuote:Why if i build over DX9 (Shader Model 3.0) the compiler generate the preshader (for the first mul and the +0.5) while over DX10 it does not generate any preshader (ruining the performance for quite a bit...)?sm 4.0 + no longer has a preshader concept.  You may as well just do this simple one off math calculation on the CPU anyway. Are you sure about this?  I don't use DX10 very much, but I can't find any references anywhere to preshader functionality being removed.  In fact the effect compiling functions still have the "NO_PRESHADER" flag listed in the documentation.Also the rationale for removing them doesn't really make sense, since preshaders are executed on the CPU and not on the GPU.Yep, i see the NO_PRESHADER flag too, anybody who have some source that tells us if the preshaders are still present in DX10 with HLSL 4.0?   ;Quote:Are you sure about this?  I don't use DX10 very much, but I can't find any references anywhere to preshader functionality being removed.  In fact the effect compiling functions still have the "NO_PRESHADER" flag listed in the documentation.Also the rationale for removing them doesn't really make sense, since preshaders are executed on the CPU and not on the GPU.OK, the full story is, the preshader and texture shader were Effects9 only.  The effects compiler could recognize uniform calculations and would pull them out and generate a preshader.  Effects would then modify the constant buffers of the original shader to receive the results of the preshader.  The nasty part here is that the preshader is really a compiled IL shader and it actually gets run on a CPU side virtual machine.  Now, if your game is GPU bound then this improves performance, if you are CPU bound, then this would make things a lot worse.So, the short answer is, you are always better off doing the math yourself on the CPU since you will always be many times faster than the virtual machine is.There were several reasons for dropping support, including performance, and the fact that most customers at the time were CPU bound and were just turning off the feature anyway.  Plus it causes other CPU overhead since effects is managing all of this behind the scenes.;Quote:Original post by DieterVWQuote:Are you sure about this?  I don't use DX10 very much, but I can't find any references anywhere to preshader functionality being removed.  In fact the effect compiling functions still have the "NO_PRESHADER" flag listed in the documentation.Also the rationale for removing them doesn't really make sense, since preshaders are executed on the CPU and not on the GPU.OK, the full story is, the preshader and texture shader were Effects9 only.  The effects compiler could recognize uniform calculations and would pull them out and generate a preshader.  Effects would then modify the constant buffers of the original shader to receive the results of the preshader.  The nasty part here is that the preshader is really a compiled IL shader and it actually gets run on a CPU side virtual machine.  Now, if your game is GPU bound then this improves performance, if you are CPU bound, then this would make things a lot worse.So, the short answer is, you are always better off doing the math yourself on the CPU since you will always be many times faster than the virtual machine is.There were several reasons for dropping support, including performance, and the fact that most customers at the time were CPU bound and were just turning off the feature anyway.  Plus it causes other CPU overhead since effects is managing all of this behind the scenes.Thanks, I think this solve any doubts i still had. :)