Jump to content

View more

Image of the Day

Boxes as reward for our ranking mode. ヾ(☆▽☆)
#indiedev #gamedev #gameart #screenshotsaturday https://t.co/ALF1InmM7K
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.


Sign up now

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

4: Adsense

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   

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.

#2 iedoc   GDNet+   

2379
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   

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   Members   

13164
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.

“If I understand the standard right it is legal and safe to do this but the resulting value could be anything.”





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.