(A thread from the slack)
Lucky DeeLucky Dee 10:40
Does anyone have a data sheet / Analysis of shader graph performance in Unity (universal pipeline) Versus raw hlsl ?
we’re having a tough time deciding if we should just convert all shaders to hlsl or if we can use the URP with close enough performance, but still be ok on mobile…
But having a hard time finding actual data on performance differences of the node based approach. Any articles or info you have would be mega appreciated. TY!
Chris CunninghamChris Cunningham 11:19
it might have slight overhead but not much if you are comparing to a HLSL shader calling into URPs core stuff
in that situation its likely does not matter, but HLSL does allow you to optimize more then shader graph since shader graph is always just having you create a node network as inputs to its existing PBR shader where in HLSL you do not need to use full PBR and could just write a simple frag/vert or doing like a lambert+blinn or something if wanted
Lucky DeeLucky Dee Friday at 11:25
Thank you ! Yeah I was mainly worried about any overhead since we want artists to also be able to adjust shaders … however in practise I found for example amplify creates a lot of garbage code on top , while I don’t expect the unity shader graph to do much overhead just feels like there’s not a lot of data on performance for it
I wonder if you can hook shader graph to an already clean shader so you know the front and back of it are nice and minimal in the context of your project
Chris CunninghamChris Cunningham Friday at 11:26
so if you do look at the generated code there is alot of stuff, but perf wise i think it will be pretty similar to a HLSL shader that is calling into
UniversalFragmentPBRsinceUniversalFragmentPBRis where most of the work both approaches would be using like even a very basic shader graph shader the generated code is huge, but i would no consider that size of that we do not know how much gets optimized away during shader compile
i would just benchmark one made by hand in hlsl and one made in shadergraph and see
Lucky DeeLucky Dee Friday at 11:31
That’s fair or at least one with a few shader variants and buffer variables .
I’ll give that a go with the memory profiler to see , thanks for the knowledge sharing !
Emil MeitonEmil Meiton Sunday at 23:51
what’s the garbage code amplify creates? I found amplify quite nice since you could just replace the base-shader things are hooked into. Is this an option in shadergraph?
I just had to doublecheck…, the feature I’m talking about in amplify is called “Templates”
for example…, I recall replacing a template both to strip out unwanted features but also to be able to auto-generate a better UI with dropdowns and parameters being hidden/shown based on what is enabled or not in the shader.This was quite some time ago now though so would love to start using shader graph again if something like templates are possible there
Steve TheodoreSteve Theodore (Slack)
@bcloward has written various flavors of PBR in shadergraph for more specific use cases than the general URP – in specific cases it’s a good idea when you have a clear idea of what your use case really is. For example on Megacity Metro – which had to run a very dense single scene on mobile at 60hz – we used a stripped-down PBR with a custom ambient term and a single baked orthographic shadow map to go faster than vanilla URP by something like 30%. However that was literally a single scene so we knew exactly what our supported gamut had to be.I’d be very leery of re-writing the HLSL by hand hoping to go faster then vanilla URP for a more general use case. The compiler is doing a lot of work behind the scenes (this is of course one reason why URP shader compile times are awful ) so the complexity of the text version is not a good guide to the complexity of the runtime code. The amount of work needed to get parity with common use cases by writing your own is really significant, particularly if you are shipping to lots of different platforms where subtleties of execution can be important.TLDR: It’s usually way easier to optimize your overall perf using the usual bag of tricks – turning off unneeded features, trimming flabby textures, limiting light counts, and good scene management – than by rewriting a lot of custom shader code. The only real exception I can think of is if you plan on relying heavily on stencil tricks which Shadergraph does not support natively. You can however write an ‘unlit’ shadergraph with a cheaper lighting / atmospheric model in shadergraph and that can give you an extra 10-30% depending on how carefully you do it. I’d definitely try that before contemplating writing all the HLSL needed to get approximate parity with vanilla URP