The Perils of Hardware Shaders
Author
So, I''ve just fiinished reading that article on pixel and vertex shaders, and I''ve decided that they are really neat. I would like to implement them in my engine, but I''m wondering what pitfalls might I run into using such a system. For instance, I was thinking that if my engine wanted to use up to say 6 lights, that the vertex shader would have to calculate 6 lights worth of code every frame, even if there where only four. So then you would have to write a different shader for each potential number of lights the game might support and switch shaders based on how many are active. I guess, in theory, this is what happens in D3D or OGL as you enable lights, even if you haven''t set the parameters for that light. Has anyone else pondered some of the pitfals of shaders? If so, I''m curious as to what said pitfalls are, and what woork arounds you''ve come up with.
The most obvious pitfall is that there''s still a lot of people out there using cards that don''t support shaders.
I wouldn''t worry about simple cases like multiple lights. You can put loops in your shaders and something like Cg or Sh will just unroll them. In Cg I think you would just use some macro like NUM_LIGHTS, and compile the shader multiple times with different values for NUM_LIGHTS.
I don''t know if you''d call this a pitfall, but lack of debugging support is a pain. The usual workflow is
1.tweak shader
2.tweak shader
3.black screen/no object drawn
4.curse; bang head on desk
5.rewrite shaders to dump every temporary you use to the output color until you find one that''s wrong.
But in my experience the benefit of programmable shading is so great you can ignore all the potential disadvantages.
"Math is hard" -Barbie
I don''t know if you''d call this a pitfall, but lack of debugging support is a pain. The usual workflow is
1.tweak shader
2.tweak shader
3.black screen/no object drawn
4.curse; bang head on desk
5.rewrite shaders to dump every temporary you use to the output color until you find one that''s wrong.
But in my experience the benefit of programmable shading is so great you can ignore all the potential disadvantages.
"Math is hard" -Barbie
quote:Original post by INVERSED
So, I''ve just fiinished reading that article on pixel and vertex shaders, and I''ve decided that they are really neat. I would like to implement them in my engine, but I''m wondering what pitfalls might I run into using such a system. For instance, I was thinking that if my engine wanted to use up to say 6 lights, that the vertex shader would have to calculate 6 lights worth of code every frame, even if there where only four. So then you would have to write a different shader for each potential number of lights the game might support and switch shaders based on how many are active. I guess, in theory, this is what happens in D3D or OGL as you enable lights, even if you haven''t set the parameters for that light. Has anyone else pondered some of the pitfals of shaders? If so, I''m curious as to what said pitfalls are, and what woork arounds you''ve come up with.
Or you could make a shader that can handle the maximum number of lights it has to deal with and then put in 0 for the light color/intensity for the others.
quote:Original post by Pragma
I don''t know if you''d call this a pitfall, but lack of debugging support is a pain.
Not with DirectX/HLSL. You can debug shaders using DX9 and VS.NET.
quote:Original post by superpigquote:Original post by Pragma
I don''t know if you''d call this a pitfall, but lack of debugging support is a pain.
Not with DirectX/HLSL. You can debug shaders using DX9 and VS.NET.
Unless you''re using Win2K, it seems..
quote:Original post by superpigquote:Original post by Pragma
I don''t know if you''d call this a pitfall, but lack of debugging support is a pain.
Not with DirectX/HLSL. You can debug shaders using DX9 and VS.NET.
öAnd WindowsXP Professional. MS have done some polls regarding the need for Win2K support, but I''m not sure what the results where.
Muhammad Haggag,
Optimize
Bitwise account: MHaggag -
Author
I thought nvidia had a shader debugger that could debug both vertex and pixel shaders. As for programming your shader to use the maximum number of lights and setting the others to black, I thought of that, but it would seem inefficient to calculate the lighting per vertex for a bunch of lights that are black, and at the moment, I only know shader assembly, so there is no conditional checking. Can CG and other hlsl systems can compile down to shader asm? Finally, as lack of hardware support goes, I thought about that too, but supposedly vertex shaders can be done reasonably in hardware, and if you don't have pixel shaders, then you just don't have per pixel lighting.
[edited by - Inversed on April 4, 2004 5:40:50 PM]
[edited by - Inversed on April 4, 2004 5:40:50 PM]
"I thought nvidia had a shader debugger that could debug both vertex and pixel shaders."
yes.
for multiple lights, nv40 has the ability to do real loops inside the shaders, that was what the demo ngill saw was about, you can download a few gdc papers about nv40 ans ps/vs 3.0 on nvidia''s developper page.
yes.
for multiple lights, nv40 has the ability to do real loops inside the shaders, that was what the demo ngill saw was about, you can download a few gdc papers about nv40 ans ps/vs 3.0 on nvidia''s developper page.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
