Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

INVERSED

The Perils of Hardware Shaders

This topic is 5191 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

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.

Share this post


Link to post
Share on other sites
Advertisement
The most obvious pitfall is that there''s still a lot of people out there using cards that don''t support shaders.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
quote:
Original post by superpig
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.


Unless you''re using Win2K, it seems..

Share this post


Link to post
Share on other sites
quote:
Original post by superpig
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.

ö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 -

Share this post


Link to post
Share on other sites
i saw a nv40 demo on the nvidia''s site with dynamic # of multiple lights in the shader

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
"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.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!