Sign in to follow this  

Can if flow control in vertex shader really skips the code and make it faster?

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

If I have a lot of math computation or texture sample operation only in some situation, is it a good idea to use 'if' to skip these code when condition is not satisfied?

Share this post


Link to post
Share on other sites
In Pre-SM3.0 shaders, code in IF statements were always executed. The
end result was just ignored if the condition was false.

In SM3.0 and above; IF block code is in fact skipped, however the IF
statement itself can be costly, so its best not to have Uber-shaders
littered with IF/ELSE blocks.

If you have any SM3.0 hardware (nVidia 6 series and above, so very
common) then yeah, the situation you described should be a good idea.

-Twixn-

Share this post


Link to post
Share on other sites
A few points to remember about flow control...

The efficiency will depend partly on granularity; a shader which gives consistent results over several pixels will be better than one which has different values for every pixel.

Also, if you are sampling a texture inside an IF block, make sure you use a gradient sample instruction( or a explicit LOD sample), because standard tex2D sample will break the flow control because of mip mapping.

Share this post


Link to post
Share on other sites
I sample texture in vertex, so I must specify lod information clearly, and this also says, I use sm3.0 or above.
Here is my doubt, at the beginning, several vertexes are processed at the same time, and later, because of skipping some instruction, some vertexes are finished earlier than other ones, at this time can these stream processor automatically take another vertex data to process? or it must wait for all the vertex processor finished? or it's hardware depend?

Share this post


Link to post
Share on other sites
Quote:
Original post by codefuns
Here is my doubt, at the beginning, several vertexes are processed at the same time, and later, because of skipping some instruction, some vertexes are finished earlier than other ones, at this time can these stream processor automatically take another vertex data to process? or it must wait for all the vertex processor finished? or it's hardware depend?
This is a valid concern and unfortunately it does depend on individual hardware architectures.

Typically pixel shader branching is more limited by this sort of thing, but it's reasonable to assume that it could happen with vertex shaders. At the very least you'll need all 3 vertices making up a triangle to be complete before the pipeline can progress - if 2 of these branch and skip lots of code but the 3rd executes the branch then the 2 fast shaders are likely to stall until the 3rd completes...

hth
Jack

Share this post


Link to post
Share on other sites
I'd think verts are less likely to have issues with different execution times than pixels - vertex assembly already has to deal with the case where some verts are in the post-transform cache and others aren't, so it would follow that it's tolerant of different length shading too. I don't think vertex shaders are grouped in the same way pixel shaders tend to be.

Either way, what you should do is profile the code and find out which is quicker and if it's an issue.

Share this post


Link to post
Share on other sites

This topic is 3624 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this