You also might consider moving branches up the pipeline. You mentioned that your shader is computing view dependent effects. You could implement a deferred shading scheme where instead of writing colors to the framebuffer, you write several parameters for each pixel to one of several textures. Then, for the final pass, you draw a screen aligned quad and shade it using your final shader that takes as input the parameters that were stored in textures from the earlier rendering pass. So what does this have to do with branching?

Well, you can write several shaders, one for each control flow condition. Then, you tile several quads across the screen, with different quads corresponding to the different regions where you wanted a certain control flow path to occur. This way, you can change control flow by changing shaders, which moves the branch up the pipeline, so to speak.

This isn't always going to be a good or graceful solution, but if you're having lots of performance problems caused by branching, this is a way to prevent pixels from taking a bunch of different control flow paths that they don't need to take.

Quote:Original post by cwhite
You also might consider moving branches up the pipeline.

Good point - theoretically any control flow can be emulated using multiple passes and predication (in particular, z-cull does a really efficient job of this). This may even be more efficient on some current cards, although those days are numbered.

Thanks for all the kind words...
I will try to tune my shader program from these advices and post the result as soon as possible. thx :)

cavatina

Quote:Original post by cwhite
You also might consider moving branches up the pipeline. You mentioned that your shader is computing view dependent effects. You could implement a deferred shading scheme where instead of writing colors to the framebuffer, you write several parameters for each pixel to one of several textures. Then, for the final pass, you draw a screen aligned quad and shade it using your final shader that takes as input the parameters that were stored in textures from the earlier rendering pass. So what does this have to do with branching?

Well, you can write several shaders, one for each control flow condition. Then, you tile several quads across the screen, with different quads corresponding to the different regions where you wanted a certain control flow path to occur. This way, you can change control flow by changing shaders, which moves the branch up the pipeline, so to speak.

This isn't always going to be a good or graceful solution, but if you're having lots of performance problems caused by branching, this is a way to prevent pixels from taking a bunch of different control flow paths that they don't need to take.

Thank you.
This seems a better solution that using different passes doing different shaders and keeps the branch instruction away. Hope I don't miss your meaning... :)

cavatina

Quote:Original post by edwinnie
Are your branches very big?
If not, better to use static branching and also not even use the "else" conditional.

Its simple. You are trying to perform conditionals in a sequential order. Have you thought about doing it in the reverse order? This method will remove the need to use "else" conditionals.

Secondly, sometimes you will find it better to abstract the instructions out of the "if" conditionals. Meaning try not to nest computations inside. This saves quite alot of instructions.

Thirdly, removing the "&&" operator by using small functions, saves 1 instruction each. Naturally, when your code increases, you will realise you can save quite a number of instructions too.

Hi, I try to abstract the real code that "if" condition needs and the FPS arises from 30 to 50. Additionally, I remove "else" conditions and rewrite the code as =>

... do something4 ...
if(...) do something1 ...
if(...) do something2 ...
if(...) do something3 ...

the FPS arises from 50 to 55.
These guildings help me a lot. thanks :)

cavatina