[Official] Feedback wanted: How to make shader loading faster / less hiccups

- Hiccups on iOS. Avoiding them by warmup if possible. (I don't care about load times) if not possible to warmup (crash) then I force them to render "hidden" at startup manually.

- I use custom shaders only, mostly IBL shaders with many textures. Variants are usually set for quality per device only and does not change after startup except those that create the environment (sky, water). I prefer to give an object it's own slightly customized shader variant (even for the LODs) if necessary instead of writing uber-shaders and I don't use cgincludes to keep control over optimization. I would say something like 50 customized shaders (maybe more) and if then maybe 6-10 variants. I don't use any instances after startup at all (pool everything) and I don't load scenes.

- Shader.WarmupAllShaders currently crashes the game (black screen without recover) on anything below iPad Air (but I still have some deactivated old rubbish in my scene) - a warmup of specified Shaders and Materials would be good instead of doing this kind of global.

- Hiccups usually only occur when the material comes into view for the first time - happens sometimes even if it is the same shader but used on a different material. Switching variants only happens in my project when the user completely switches "screen content" so if there is any hiccup then I haven't noticed it yet.

 

Great I'm working on Ori and the blind Forest. We have our own shader permutation system (with our possible permutation space, billions, multi compile just wasn't viable). A full game build today contains about ~1500 shaders. Almost all shaders have 3 variants in them (multi_compile)


The are 3 main problems we’ve encountered:


1. Loading shaders at runtime causes hiccups, on almost all platforms, we're always close to 16 ms. We of course do shader prewarming shaders, but:

2. Shader.WarmupAllShaders only warms up the shaders that are currently loaded... That means that we have to do some voodoo build magic to actually load all included shaders in the first scene, warm them all up, and then keep them loaded. That leads to:

3. Loading _all_ shaders in memory, especially in the current format (as you mentioned in the other post), becomes quite huge. In the orders of ~50MB, which, on 360, is as much as our graphics budget. Additionally, warming up 1500 shaders really bloats game loading times


Here are my thoughts on a direction to take here


1. (option to strip out variants manually)

Reducing the number of variants is crucial to making shader_feature useful for more than simple stuff. The exponential nature of variants means that it will _always_ explode the amount of variants. Additionally, often some combinations aren't even valid, as in, not compiling. Having some kind of matrix similair to the physics layers would solve that. How that would look is tricky - per shader, stored in the .meta file could work. Either way, it's the only way to keep shader_feature managable.


2 / 3: (Delay loading of variants, rework Shader.WarmupAllShaders, timesliced loading)

I would propose a system where, when a material gets loaded (so not when it's rendered, but when say a scene gets loaded) it should warm it's _current_ shader variant (or, current + a few light modes). When someone changes keywords at runtime it would mean warming a variant at render time, but I feel that that is much less frequent.

When calling LoadSceneAdditiveAsync, it would mean warming the shaders time sliced as the materials come in (I realize that this isn't how it actually works, but conceptually speaking). This would be on the loading thread so it wouldn't interrupt gameplay.

Ideally shaders would not just unload when they're no longer referenced, but also unload variants that haven't been used in a while.


4. (the other forum topic)

Yes, please change that compiled shader format I'm 100% for it, no real downsides, major upsides for us. Less memory, less parsing.


Also, it seems that a build for a platform only should have the compiled version for the target platform. Or is there some deeper reason for that? (fallbacks maybe?)

Really excited to see these problems starting to get traction, hopefully they can be resolved If you need any more info let me know!

 

Don't mean to hijack thread but:
How does #pragma shader_feature work and how does it differ from #pragma multi_compile ?

 

Thanks for the explanation and looking forward to using shader_feature in 5.0

 

Shader.WarmupAllShaders makes the game to pause for sometime..Any Help???

 

Thanks Aras
But i didnt get the idea of making the shaders small.can you post an example?

 

Thanks again. Aras
Can you suggest me tutorials to start with shader scripting.Wll be a great help.

 

http://en.wikibooks.org/wiki/Cg_Programming/Unity

 

Hi, I am trying to build an uber shader in a whole game project, with many shader_feature control them.
But I when I use about 18 different shader_feature, the unity become almost unuseable, and when it loading, it take about more than 8G memory.
Am I use the wrong way?

 

It's probably just a ton of different shader variants.
Following the example below, a shader with 18 multi_compile features with two options each feature, should generate 2^18 = 262144 variants in total.

Copied from the documentation:

 

I think unity can optimise this behaviour by create actual shader when it needed, and cache them in the Library folder.
Just like the Gamebryo shader tree or something like, keep an hash map with the compile keyword in the memory, each time need a shader, lookup the table, it there is nothing existed, try load from cache on the disk, if the disk cache is not exist, then create a new one.

 

Hi, I'm currently looking into this exact issue, laid out by Aras here:

Is this the case? Do shaders get unbound from gpu when calling UnloadUnusedAssets?
(Using Unity 5.4.1p4 atm).

Thanks!