ShaderLab taking 300mb of memory (IOS)

Not sure what this is, according to the profiler, "shaderlab" is taking up 300mb of memory on my game on iOS.

We mainly just use the standard shader and a few customs shaders.

What on earth is causing this?

 

Anyone have the slightest idea? Have searched everywhere online and can't find any details on it.

 

got the same issue, I just use standard shader to all buildings in the scene, about 500+ buildings
and build the windows exe, the profiler shows the shaderlab has large memory usage (Unity2017.3)

 

Same issue. Could this have something to do with asset bundles?

 

Anyone find a resolution to this? I'm having the same issue with large ShaderLab memory on iOS.

 

I'm having this problem on 2/3 of my platforms, including PC. Two use ~750MB shaderlab, one uses ~250MB shaderlab.

I'm not targeting iOS though, so seems to be a cross-platform bug. Just comparing settings between them, I haven't yet been able to figure out why.

 

Does anyone from Unity have a word on this? This is the second thread (here's the first one) about this same issue and we haven't heard anything about it yet. @aleksandrk ?

I'm profiling on Android, using Unity 2019.2.15, OpenGLES 2, no SRP. The ShaderLab memory peak is only noticeable when the Standard shader is being used. If I use a Mobile shader instead, ShaderLab's memory drops drastically. If switch to another scene which doesn't use the Standard shader, the memory usage drops as well.

 

Can we somehow reliably exclude the Standard Shader from builds?

 

The excessive amount of memory used by ShaderLab was gone after I updated the project to Unity 2019.2.21. I couldn't find anything related to this issue on the release notes from 2019.2.16 until 2019.2.21, but I'm glad it's fixed now.

Thank you so much for the quick response.

I understand that the Standard shader has many variants, but I expected that to be registered in the profiler under "Assets>Shaders" (and it is). Although, I don't understand why ShaderLab would take 250Mb of memory, even after the scene load. To be honest, I still don't know exactly what falls under "Other>Graphics>ShaderLab" and I couldn't find any documentation or forum post explaining what's that exactly. For now the problem is solved, but if you could shed some light on that subject. I'd definitely appreciate it.

 

Somehow I had missed that blog post. Thanks!

 

A little more than a year ago I ran into the same issue: https://answers.unity.com/questions...-grow.html?childToView=1703215#answer-1703215

I still had this issue on 2018.4.11f1 - I'm not sure about newer versions.

At the end of the day our problem specifically was shader duplication due to asset bundles - materials that share a shader, are explicitly referenced by bundles, and also implicitly referenced by bundles (i.e. 'pulled in' by other assets) will cause the shader to be duplicated - same shader, but the asset system seems to treat them as different shaders.

My fix was to do the steps outlined in the answer - a combination of step #2 :"bundling all materials / shaders into a separate asset bundle and putting it into the streaming assets folder, and loading that asset bundle at runtime on demand" and step 0: Remove usage of any and all 'hidden' built-in shaders - replace with 'custom' copies of the shaders from Unity's repo, and make sure those shaders are included in the asset bundle from step 2 (including the standard shader if you are using it) - seems to be the key thing to preventing the duplication.

 

@aleksandrk - I think we all can understand that ShaderLab covers "any memory allocations on the engine side that are marked 'ShaderLab'. The issue is we have no insight into what "whatever else is required there" is.

I have some questions:

1. Does the memory covered under "ShaderLab" include only shaders that are being referenced by assets currently loaded, or does Unity cache shaders that might be referenced in the future (i.e. shaders that are included in the build but not yet referenced in memory through loaded assets)?
2. Depending on the answer to #1, does ShaderLab continue to grow as more and more assets are loaded? Will periodic calls to UnloadUnusedAssets reduce usage?
3. Does Unity store all variants of a shader in memory when that shader is referenced by an asset, or only the variants currently needed by that asset?
4. What aspects of a Shader/Material are represented under "ShaderLab"? Presumably there's the shader source itself which will be needed to be supplied to OpenGL - but does the shader source hang around after the OpenGL program is created? If not, are we seeing the memory cost of the compiled OpenGL shader program under ShaderLab, or just the source code? What else?
5. Is there any way to see what the makeup of "ShaderLab" memory is through the new memory profiler obtained through Unity's Package Manager? From what I can tell, we can see all the allocs, but with no way to determine what they are or where they came from.

0.6GB for Shaders seems incredibly excessive, and I find Unity's near-silence on this subject a bit alarming - I've yet to work on a Unity project that doesn't suffer from excessive ShaderLab memory usage, but I am unable to find anything online that details what contributes to it or how to deal with it. Have we been doing something wrong on all those projects I've worked on? Probably! But a little more insight into what's going on would help us determine that, and help us avoid making the same mistakes.

Can someone from Unity please chime in and provide some additional insight here. I know someone mentioned above that it was magically fixed in 2019.2.21, but there are many of us working on projects where we can't just upgrade at the drop of a hat, so it would be really useful for those of us still on 2018.x (or 2019 prior to 2019.2.21) to be given more details of what the issue(s) are and what was changed in that version to address them.

Thanks

 

@aleksandrk - thanks for the more detailed response and for answering the questions.

For #5 - is there someone on your side you could ask or get to chime in? The built-in memory profiler literally only says, "ShaderLab X MB", which gives us very little to go on. The new memory profiler lists each allocation both on the native and managed sides, from what I understand. After a lot of digging, I have managed to find the allocations tagged as ShaderLab in there (since my first post) - but, they come with no annotations or anything to indicate what causes them or what they are comprised of - we effectively only see memory addresses and the size of the allocations.

Is there any way at all currently (and by currently I mean in the 2018.x range of Unity) to get more information on what is contributing towards that "X" MB?

 

We are, yeah. I saw mention in other threads of the same shader being referenced in multiple bundles counting as multiple shaders in the ShaderLab count. Is that what you're referring to? If so, what is the best way to address that?

 

This is a very useful tool - thanks for pointing to it. I'll dig deeper with this and see what I can find.

 

I'm having similar issue with ShaderLab on a project I'm part of; I've tried using that tool to analyze the asset bundles we're producing, but the script ends up running into a crash and can't parse through all the bundles (and unfortunately, those are the bundles that contain the helpful information I need).

Curious if anything has changed to the way Asset Bundles are built in Unity over the last couple of years, since the script for this tool hasn't been updated in about 2 years

Any information and help is super appreciated

 

Thanks aleksandrk; that would be very helpful
hopefully that can help shed some light on the issue.

 

What if we aren't using asset bundles? Memory from ShaderLab is 237 MB in the profiler on iPhone
@aleksandrk

 

But the editor log is for disk space, not runtime size, right?

 

I got the same issue on Android and ShaderLab can take more than 800 MB on my project:

It's the main issue I'm facing and it cause memory crashes as soon as I load more complex scenes.

I made some progress recently and managed to reduce Shaderlab to 100kb (!) by simply stripping all shaders with an IPreprocessShaders script. Issue is all things are pink now , but at least it prove that it's related to stripping shaders.

Currently I'm working toward finding the shader causing the memory to rise so high by guessing and eliminating them one by one. I already stripped some of them with a minor inpact (around 20mb down), but my next target is the default URP Lit, I have high hope on it as it take ages to create shader variant of it and as I suppose I should use simple lit for mobile.

Strangely the shaders seem to still be visible in the profiler when I strip them, I don't know why, but when I removed them all they was all pink and ShaderLab was 100kb so it definitely work.

I'm currently using Unity 2019.4.9, URP/VR with addressables and asset bundles.

Edit: Ok so I just removed "Universal Render Pipeline/Lit" and ShaderLab is now 67mb
Now I need to find a way to automatically change Lit to Simple lit for Android build...

Edit 2: After changing all the Lit shaders to simple lit, ShaderLab is now around 375mb!
Still pretty high, and if I take a look at the memory profiler (on windows, unfortunately doing a capture on Android freeze Unity), it seem that I can't do much better as it's now simple lit taking the most memory (if ShaderLab and shader memory is linked)

I guess it's because there is many variants, but I don't know what I could do to reduce this.

Hope this help others!

 

Nice find, 375MB is still insane though! Easily over 1/3 the RAM you will be able to use on any 2GB iOS device, and those are still fairly recent. Let me know what else you find please! I had some luck stripping unused lightmap modes in the graphics settings.

 

For future reference :

I picked up Shader Control : https://assetstore.unity.com/packages/vfx/shaders/shader-control-74817 from the asset store and messed with the settings. I am still messing with them, but so far it has made a massive improvement in runtime shader memory usage.Would definitely recommend for anyone else dealing with this problem.The big thing is removing variants that you know you won't use

 

Wonderful news!! Anything that makes the memory profile better brightens my day.

 

Sorry, I have deleted my question(hadn't seen that you had already answered), because it was not anymore needed. But you were so fast! Big Thanks!

 

Any news on this? Same issue in android for me. near 300mb lit shader in 2021.2

 

Also the problem seems to be that in some cases, all the shader variants get loaded in right up front. I think this is a bug because the unity documentation reports otherwise and it seems that sometimes it does work correctly. From what I have seen it appears to work correct on Android more than iOS.

 

Ah I see. Thanks for the explanation. But why?

I mean it's not really a problem for us anymore because we wrote our own shader variant kind of system, but it was a huge problem before that. The game used to crash before even hitting something visible in game due to it loading gigabytes of shader memory.

 

I agree this might be some kind of bug, or at the very least a configuration issue associated with addressables.

I did not have this problem until we started making builds with addressable fully implemented.

 

I have same problem. The game is crashing on iOS because of out of memory. Can someone help ?



Unity version: 2020.3.1
Device: Iphone 7 on iOS 14.0.1

 

This is pretty much expected, the Standard shader generates a lot of variants and memory usage can get out of hand quickly.

 

I also got shaderlab consumes some big memory (130mb), how to diminish this?