Shader.Parse taking a long time according to Unity Profiler

Hello folks,

So, my scene is taking a lot time to load and, after analyzing the profiler, looks like a bottleneck is caused by this Shader.Parse. I Google'd a bit but I can't find a solution nor a reason that can explain why Shader.Parse is taking a bunch of time.

A reasonable argument would be that I have a lot of shaders to load, but actually it isn't (unless I'm missing something, but what?).

So, yeah. What are the common causes of Shader.Parse to take so much time? Any fixes or tests to prove that I am wrong?

Thanks in advance.

 

Hello,

We're currently on 2018.3.4f Win10. I can't see any specific shader being too slow, also, I can't profile the GPU because profiler says to "update my GPU drivers". Which are already up to date.

I also tryed to preload shader like suggested here: https://forum.unity.com/threads/preloading-shaders-doesnt-help-with-performance.533838/

If you've got any suggestion on how can I help you, please, let me know. I'll do my best.

Cheers.

 

Hi,
on loading map, for Xbox, I've a gigangic spike due to Shader.Parse too. On PC is not that much of a deal but its because I've a powerfull one.
I use standard shader like for 99,9% of the stuff in scene.
That GPU drivers message, try dissabling graphics jobs may be I think I did get that message in the past.
Last time on certification they called my attention on this issue because it kinda freezes right before launching the match... 2018.4.9f1

 

profiling xbox build

 

@richardkettlewell Is this issue tracked anywhere? I'd like to see if the improvements have been added to any Unity 2019 version.

 

I recently noticed after upgrading from 2018.4.2 to 2018.4.23 that I'm getting large Shader.Parse spikes where I didn't before (while async loading a scene). Is there any way to get around this? Prewarming the shaders seems to make no difference now.

 

I ended up updating all the way to 2019.3, which removed the stutter introduced in 2018.4.23. Now I just have to QA my entire game again

 

We're on 2020.1.0f1 and having this exact issue on Xbox. Any updates?

 

If you are using asset bundles built with the legacy build pipeline (like Asset Graph) it simply does not support assigning built-in Unity assets to bundles (including built-in shaders and built-in meshes like Plane and Cube). The legacy pipeline can only assign asset bundles based on asset paths and the built-in assets don't have a valid one (also, AssetDatabase.GetDependencies() does not detect built-in assets either).

What happens when building the bundles is that the built-in assets referenced by the assets in your bundles get the same treatment as any other dependency that doesn't have a bundle assigned to it: it gets copied into each asset bundle that depends on it.

This is why using ShaderVariantCollections to warm up built-in shaders fail: each bundle will load a fresh copy of the shader, that needs to be Shader.Parse'd into the GPU again for each newly loaded bundle.

The ContentPipeline API behind the Scriptable Build Pipeline is capable of assigning bundles to built-in assets, since it assigns bundles by asset reference, not paths. It also has dependency collection functions that, unlike AssetDatabase, can detect built-in assets correctly (it even correctly reports built-in shaders set as custom shader fallbacks as dependencies).

However, depending on how far along your project and how it's set up, switching from legacy to scriptable build pipeline is not feasible (there's also the question of the SBP being newer, not as battle-tested as legacy, and largely undocumented beyond very basic use cases).

The "solution" then is to download the built-in shaders for your Unity version, move them all into your project, then replace all references to the built-in shaders by the imported ones. This way you can assign them to a bundle that will be correctly registered as a dependency of any other bundles that reference them, and you can put them into a ShaderVariantCollection (loaded from a bundle) and warm up them correctly.