In a webgl pixel shader, all functions are inlined as i understand it, however you can have parameters that are marked as in versus being inout meaning that their value can change but the value won't persist outside of the function call.

Does this mean that the shader must make a copy of the value for the function to work with when it is an in value?

Are shader compilers/optimizers smart enough to know when they don't need to make a copy, or is it best to really just mark up all parameters as inout and make sure and not modify the ones you don't want modified, if performance is the primary concern?



My experience working with shader compiler stacks a few years back is that they are extremely aggressive, and I doubt you will see any perf difference, but I would suggest testing as much as you can.

I would generally recommend providing the compiler (and human readers) with more information where the language allows it, marking parameters according to their usage. Treating an in-only parameter as in/out is more error prone for humans than compilers.

Some detail: shaders run almost entirely using registers for variables (I worked with architectures that supported up to 256 32 bit registers) - spilling is hugely expensive. Physical registers are shared between shader invocations - think of this as threads in a HyperThread sense sharing a register pool - and if the shader can be complied to use fewer registers there's greater parallelism. The result is shader compilers work very hard to minimize the number of registers used - without spilling, of course. Thus inlining is common since it's desirable to optimize register allocation across the whole shader anyway.


Your Answer

