Official Dynamic shader variant loading

@aleksandrk

Thanks sounds good. Waiting for the backport to 2021 LTS
Updated the project from 2019 lts to 2021 1.5 Weeks ago increasing the build time by xx% because of shader variants going into the millions.

Any idea when we can get a fix for 2021 LTS?

 

This looks to be a change to runtime shader loading. So it won't affect compile times at all.

 

Do we have to do anything to enable it or it just works straight away?

 

Just to make sure, it will be available in 2022.2.0+ as well? Aka all versions that will come from now on? Dynamic shaders will work on webgl as well? I am already waiting for Monday to try it out

 

Greetings. So I am working with Unity 2022.2.1 now ( tho same goes with all previous versions) and addressables package. So here I have a problems, this is workflow that I expect to work:
1) Go to Player Settings -> Graphics -> Save Shader Variant Collection.
2) Add that SVC file to addressables.
3) Build addressables with addressables scenes.
4) In Player Settings -> others I set shaders default chunk size to 16 and default chunk count to 2
So expected behavior is, then when scene starts and loads, shaders loaded to memory will be only the needed ones. However what I get is shaders using over 300 mb.

Spoiler: Memory profiler report

With custom shader striping code I am able to reduce it to ~100 mb.

So my question is it I am doing something incorrect? is it problem of addressables? Or there is something I am missing to use dynamic shader loading?

Extra info:
Platform: WebGL
43 shaders and total 91 variants used.
In editor URP Lit uses 0.8MB

 

First of all, thank you for your time,

I know that this is more problem with Addressables than dynamic shaders, but I am very thankful for your help.

After reducing chink size to 1mb the memory size of URP/Lit got reduced:
- Universal/Lit shader is in Packed separately addressables group together with Shader variants collection: to 67.6MB.


-Universal/Lit shader is NOT ADDED manually to addressables group, but Shader variants collection is added manually into addressables group: to 273.8 MB.


From these results I could guess that Addressables does load all possible shader variants by specific keywords. When everything is in same Addressables group it does load less. But regardless of that the size of loaded shaders in memory is still way too big, from what I can only guess that dynamic shaders loading does not work fully with it.

Example in Editor the URP/lit reports at about 0.4 MB of memory (as editor does not use addressables directly.).

 

On iOS, this literally slashed my app's total memory useage in half. Fantasic work, crew.

 

Firstly, I'd like to say that I've very limited information about how shaders are processed, so my question may make no sense (understandably): Could you explain why decompressed chunks stay in memory? If we're done with them once they are uploaded to the GPU, I couldn't understand why they remain in the memory. If we need them while the shader is in-use, then if we set the maximum number of chunks to 1 and multiple shader variants (chunks) are used by the scene, won't these chunks fight for the single available chunk slot, causing an infinite loop?

 

OK so it's like cache prefetching in a way, got it! Thanks for the explanation 0.02 ms difference per variant with default settings sounds like a very insignificant con so the pros heavily outweigh the cons IMO, thanks for the new feature!

 

This is great, we are fighting with shader variants and this helped to reduce our memory usage on scene load by 50%

Would you be able to give more detail on the maximum chunks value?
the maximum number of chunks that are kept decompressed simultaneously for each shader at runtime.

Kept decompressed where? In memory I assume?
What happens to chunks which are no longer needed or the number of chunks needed is > maximumChunks?
If unneed chunks stay in memory are they compressed again to save memory?

Finally, is there any way we can gauge a good chunk size and max number of chunks?
It sounds like once stuff is loaded into memory its not unloaded from your other comments. So if we know we have lots of variants, because we aren't stripping them yet, setting the chunk size to 1MB and 1 chunk max would theoretically load in the fewest variants we need and avoid the bloat from the unused variants?

 

Thank you for the information, that really helps!

 

Hi @aleksandrk

Will the "dynamic shader variant loading" help improve build times? (Not at runtime) .. sorry I'm new to all this.

Can we trouble someone on the Unity team to make tutorials on how to reduce the shader variants compilation time? Or at least best practices?

I've been trying to make a build the whole day .. my pc is still building.. it's probably at 9 hours now.

I'm clearly not doing something right..

Unity 2021.1.28f1


Thanks for the help

 

You're on 2021.1, not 2021.3. 2021.3 is the LTS (Long Term Supported) version that comes out after the end of the year and gets the long-term maintenance and sometimes backported features. So you'll have to upgrade to that version if possible. Just make a backup of your project first in case there's something in your project that ends up having obsolete API in 2021.3 and can easily revert if you need to.

 

I'm going over the material now. Seems I'll need to update to 2021.3 to access the new tools. Crossing fingers nothing breaks. Thanks for the links !

 

Hi, first I have to admit I have little knowlegde in shaders so it is possible that my question might not make much sense
I was wondering how "Dynamic shader variant loading" and "shader variant prewarming" can work together properly?

Our game lets users upload their own 3d models. I ran the game, loaded those models, created a shader variant collection, and added it to Preload shaders in Graphics Settings or call WarmUp() in Awake() to prewarm it.
However, variants in that collection are taking nearly 300mb memory. We've tried to strip the variants, but in our case it's really hard to strip more.
After seeing this new feature "Dynamic shader variant loading" I am testing it now. With my collection placed in Preload shaders in Graphic Settings, I set chunk size:16mb & chunk count:5. The build indeed uses less runtime memory(220mb) than before.
But what I can't understand is:

From what I read in How Unity loads and uses shaders doc:

1. When Unity loads a scene or a runtime resource, it loads all the compiled shader
   variants for the scene or resource into CPU memory.
2. By default, Unity decompresses all the shader variants into another area of CPU memory. You can control how much memory shaders use on different platforms.
3. The first time Unity needs to render geometry using a shader variant, Unity passes the shader variant and its data to the graphics API and the graphics driver.
4. The graphics driver creates a GPU-specific version of the shader variant and uploads it to the GPU.

and:

• To avoid visible stalls at performance-intensive times, Unity can ask the graphics driver to create GPU representations of shader variants before they’re first needed. This is called prewarming.

My understanding is that prewarm happens in 4(creating a GPU-specific variant), but not 1(loading variants into CPU memory).

Will "Dynamic shader variant loading" make some variant not loaded? (my 300mb reduced to 220mb) If so, is my prewarm still working effectively? (if the variants are not in cpu memory, how do I prewarm them?)

It would be awesome if you would help me figure it out. Thank you for reading!

 

Anyone care to share their suggested values for relatively simple games, like "Boat Attack", targeting iOS, Android and webGL?
for PlayerSettings.SetDefaultShaderChunkCount & PlayerSettings.SetDefaultShaderChunkSizeInMB