Are functions or macros better for short gdshaderinc methods?

Question

I don't actually know how costly a function call is in a gdshader. Is it worth it to use a macro for a one-liner over a function? I'm having a hard time finding an opinion on the internet about this. It's all people arguing regarding C++, and gdshaders don't have inline so those arguments don't help me much!

Bes

Answer 1

help me out. what does macro mean in this context?
its one of those words i've pretended to understand the past few years.

Hastings

Answer 2

Code replacement. This page explains them for Godot shaders.

Essentially, you do something like #define SQUARE(x) x*x (just as a trivial example)

Then later on, if you write float y = 2. - SQUARE(z);, the compiler will replace the code with float y = 2. - z*z;

You have to be careful because it is a direct text replacement. So if you did:

float y = 2. - SQUARE(z + 1.); the compiler would expand it to float y = 2. - z + 1.*z + 1.;, which likely was not what you were trying to do. Since they're so prone to error, it's best not to use them unless they give you some advantage.

Bes

Answer 3

I think you needn't worry about it. Use functions normally. The compiler will likely inline it all. It's much easier to code that way. You can always flatten stuff out once the shader is done and proven as a bottleneck.

Carey

Answer 4

If you're willing to go deep, you can compare SPIR-V code in each case: https://shader-playground.timjones.io/. Just be warned that looking at that stuff can fry your brain as it's primarily made to be machine rather than human readable. Further down we cannot go because GPU machine code varies greatly between vendors/products and is not published in most cases. There are some urban legends that GPUs don't even use stacks but I doubt they are true.

Carey

Answer 5

in that case, gdshader seems fast enough. the potential time loss debugging a weird macro i think outweighs the performance benefit, if it exists.

unless it is something as simple as x*x. you probably won't lose much time debugging that. probably.

Hastings