Feature Request URP/HDRP Shader graph code gen optimization

Is there any plan to make URP/HDRP Shader graph code gen much more efficient and optimized shader code that can compete with hand written shader code? From what I know currently the performance is still very slow compare with hand written code.

 

HLSL is a very simple language - most of the code written by a shader graph gets optimized out by the compiler, because it's lots of temp variables, etc. So the size of the output code you see is not necessarily indicative of the performance of that code.

The slowness between hand written vs. shader graph code is usually not at the compiler level, as much as it's about who's writing it. There's a common misconception that writing in a shader graph produces slower code, but that's not always the case.

For instance, if you make a shader graph that samples two PBR texture sets and blends them based on a slider, it's likely going to produce code that runs just as fast as hand written code does. But when you get into more complex 'system' level shaders, like terrain shaders, which can sample hundreds of textures, there are more opportunities for optimizations to be easily hidden by a graph.

For instance, when you sample a normal map in a graph it doesn't write:

Code (CSharp):

1. float3 normal = tex2D(_tex, uv);

it writes:

Code (CSharp):

1. float3 normal = UnpackNormal(tex2D(_tex, uv));

With the unpack normal function doing some math operations to convert the normal to -1 to 1 space and reconstruct the Z component using a sqrt.

However, if your shader is working with lots of normal maps, it can take a shortcut of blending them together and reconstructing the Z component at the end, saving a bunch of math (with some possible mathematical differences that are visually hard to see IMO)

You could do this same optimization in a shader graph by understanding the code it's writing and changing the graph - but being at a higher abstraction we tend to forget about the code that it's actually writing. And as a shader graph node encapsulates more code, the problem might grow. But you could write the code for that abstracted node in a more efficient manner for your use case manually instead of using the nice version.

Finally, there are things just not exposed in a graph - like proper branching, which would be difficult to expose and explain to the average graph user.

As such, I'm a big fan off node graphs for customizing one off shaders for art assets, but not a big fan of them for large systematic shaders like terrain shaders and mega-shaders. However, the new blocks framework, might provide some hope of being able to combine the best of both worlds here.