Jump to content
  • Advertisement
Sign in to follow this  
TheKrust

Quck questions about shader instructions...

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

I know there's a strict limit on how many commands a pixel shader can take, is there a set number on vertex shaders as well? If so, is it (probably) a much larger amount of instructions? That would make sense to me because there are not nearly as many vertices as there are pixels and, of course, this lightens up a lot on the GPU. Also, is it possible to have shader 2.0 and 3.0 as an option in games so that you can adapt to older hardware?

Share this post


Link to post
Share on other sites
Advertisement
see Wikipedia page on HLSL.

There is an instruction limit for vertex shaders and depending on the shader model it may or may not be higher than that for pixel shaders. (note that dynamic branching supported by higher shader models will help a lot in staying below the instruction limits)

About your second question: It's absolutely possible to use several shader models in the same game. Half Life 2 does this very effectively for example. However, a lot of the more complex shaders found in modern games cannot easily be done with lower shader models, hence, modern games running on old hardware tend to look pretty bad (worse than games made specifically for that hardware)


Share this post


Link to post
Share on other sites
Quote:
Original post by Harry Hunt
However, a lot of the more complex shaders found in modern games cannot easily be done with lower shader models, hence, modern games running on old hardware tend to look pretty bad (worse than games made specifically for that hardware)


That does explain a lot. Team fortress looks great on my computer, but on some others, it's very plain and just overall bad looking. The cards are (of course) not able to support 3.0.

Thanks for the link, very helpful. And yes, vertex shaders can take far more instructions than pixel shaders.

About "Dynamic Branching", are you talking about putting function-like structures inside the shaders and it will work fine as long as you don't exceed the instruction count?

Thanks a lot though.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheKrust
About "Dynamic Branching", are you talking about putting function-like structures inside the shaders and it will work fine as long as you don't exceed the instruction count?

Branching is when code can take different paths depending on certain run-time values. The best example I can think of for branching is an if statement.

Dynamic branching is when branching is handled as you'd expect it to, the processor looks at the value and determines which path to calculate. Until recently, GPUs were not capable of doing this at all, and even now suffer somewhat of a penalty handling dynamic branches.

Other than Dynamic branching there's what's usually called static branching. In this case, all code paths are calculated, and then the results are selected using a numeral calculation of some sort. This has the down-side of requiring calculation of both code paths in either case, but allows the GPU to treat your code as it would any other code, and not perform special operations to handle branching. Also, this is more widely supported.

Share this post


Link to post
Share on other sites
Well "If" statments are easy enough, and while it may slow the program down a little, it's a lot better than swtiching pixel shaders for every individual task (major preformance drag).

Share this post


Link to post
Share on other sites
Quote:
Original post by sirob
Other than Dynamic branching there's what's usually called static branching. In this case, all code paths are calculated, and then the results are selected using a numeral calculation of some sort. This has the down-side of requiring calculation of both code paths in either case, but allows the GPU to treat your code as it would any other code, and not perform special operations to handle branching. Also, this is more widely supported.


That's not what static branching refers to when talking about shaders. Static branching in shaders is branching that depends on a value that is constant for an entire draw call - you set the value once before dispatching some geometry and that value holds for every vertex / pixel rendered in that draw call. Dynamic branching is different because the value that is being tested for the branch can change per vertex/pixel and is not fixed for the duration of the draw call. Static branching can be used for turning on and off features of a single shader for different objects, or for looping over the number of lights that affect a particular object.

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.

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!