Jump to content

  • Log In with Google      Sign In   
  • Create Account

Does using a program like Fx Composer or RenderMonkey cause performance loss over writing your own shaders?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Veil   Members   -  Reputation: 143

Like
0Likes
Like

Posted 24 May 2012 - 07:21 AM

I wrote a couple of shaders for myself(parallax mapping,some fun with water),but nothing really special looking,since I'm not good at it yet and using a program sounds tempting,but when I do that,the shaders come out with 10 times more variables and code than I usually use.

Sponsor:

#2 iedoc   Members   -  Reputation: 969

Like
1Likes
Like

Posted 25 May 2012 - 02:08 AM

yeah, when using a program like those, you will have to go over the code and optimize it yourself. The reason is mostly because these programs give up a little performance for flexability as far as i know.
Braynzar Soft - DirectX Lessons & Game Programming Resources!

#3 Veil   Members   -  Reputation: 143

Like
0Likes
Like

Posted 25 May 2012 - 07:13 AM

yeah, when using a program like those, you will have to go over the code and optimize it yourself. The reason is mostly because these programs give up a little performance for flexability as far as i know.

yeah, when using a program like those, you will have to go over the code and optimize it yourself. The reason is mostly because these programs give up a little performance for flexability as far as i know.


yeah,by the way,the programs sometimes output a shader code with if/else statements,isn't that bad for HLSL?Why exactly is flow control bad for shaders?

#4 Bacterius   Crossbones+   -  Reputation: 8885

Like
1Likes
Like

Posted 27 May 2012 - 08:37 PM

Why exactly is flow control bad for shaders?

It's not "bad", it's just the GPU can't deal with it as easily as a CPU would. Basically, in your GPU threads are arranged in groups of threads, and these groups*must* have the exact same codepath (you can already see how conditionals would hurt that). Now if your conditional is based on a constant (say: if (textureWidth > 512)) then there is very little cost (equivalent to a couple ALU instructions), however if you have a more complex conditional based on the current pixel (like if (pixelDepth > 0.5)), then if two threads in a thread group evaluate the conditional differently, then *all* the threads in the group must evaluate *both* possible outcomes and then choose the correct one at the end. Ouch.

So as long as the conditional is somewhat coherent among threads in a group, it will be fast, however if it evaluates to something relatively random for each pixel you'll get a massive slowdown as every possible outcome of the shader is executed for every pixel before deciding which one to use.

Edited by Bacterius, 27 May 2012 - 08:38 PM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS