/
Shader.WarmupAllShaders
Prewarms all shader variants of all Shaders currently in memory.
For information on shader loading and prewarming, including a list of different prewarming techniques, see Shader loading.
While this method can be convenient, prewarming a large number of shader variants can result in long load times and high memory usage. If this is a problem, consider placing shader variants in a ShaderVariantCollection instead.
Warning: This method is fully supported on DX11 and OpenGL. On DX12, Vulkan, and Metal, the graphics driver might still need to perform work if the vertex layout and/or the render target setup is different from the data used to prewarm it. This can result in wasted work and GPU memory, and still leave visible stalls in your application. ShaderWarmup is supported on all graphics APIs.
Additional resources: ShaderWarmup, ShaderVariantCollection.WarmUp, Shader loading
How Unity loads and uses shaders
Unity loads compiled shaders from your built application in the following way:
- When Unity loads a scene
or a runtime resource, it loads all the compiled shader
variants for the scene or resource into CPU memory. - 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.
- 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.
- The graphics driver creates a GPU-specific version of the shader variant and uploads it to the GPU.
This approach ensures that Unity and the graphics driver avoid processing and storing all the shader variants on the GPU before Unity needs them. But there might be a visible stall when the graphics driver creates a GPU-specific shader variant for the first time.
Unity caches each GPU-specific shader variant, to avoid another stall when Unity needs the shader variant again.
Unity removes the shader variant completely from CPU and GPU memory when there are no longer any objects that reference the shader variant.
Which shaders Unity loads
Unity only loads compiled shaders that are compatible with the platform’s graphics API, hardware and graphics tier.
If Unity can’t find the shader variant it needs because you or Unity stripped the shader variant from your built application, Unity tries to select a similar shader variant. If Unity can’t find a similar shader variant, it uses the magenta error shader.
You can enable strict shader variant matching to stop Unity trying to select a similar shader variant.
How Unity selects a subshader
If a shader variant contains multiple subshaders, Unity tries to select and use a single subshader that’s compatible with all of the following:
- The platform’s hardware.
- The current ShaderLab level of detail (LOD).
- The active render pipeline
.
Unity searches for the first compatible subshader among the following elements in the following order:
- The subshaders in the order they appear in the shader.
- The subshaders in any fallback shader objects
, in the order they appear in the shader objects.
If Unity can’t find a compatible subshader, it uses the magenta error shader.
You can set which subshaders are compatible with which hardware using ShaderLab
tags. See ShaderLab: assigning tags to a SubShader.
Prewarming shader variants
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.
You can prewarm in the following ways:
- Prewarm a Shader object or shader variant collection using the Experimental.Rendering.ShaderWarmup API.
- Prewarm a shader variant collection by using the ShaderVariantCollection.WarmUp API.
- Prewarm all variants of all Shader objects currently in memory using the Shader.WarmupAllShaders API.
You can also add shader variant collections to the Preloaded shaders section of the Graphics Settings window. Unity uses the ShaderVariantCollection.WarmUp
API to load and prewarm the shader variant collections when your built application starts.
Prewarm on DirectX 12, Metal or Vulkan
If you build for DirectX 12, Metal or Vulkan, the graphics driver can only create an accurate GPU representation of a shader variant if it knows the exact vertex data layout and render state. If a prewarmed GPU representation is inaccurate, Unity might still stall when it needs to create the accurate representation.
To create accurate variants and avoid stalling, you should prewarm by rendering Materials off-screen.
You can also:
- Prewarm a Shader object or shader variant collection using
Experimental.Rendering.ShaderWarmup
, but only if you can provide the vertex data layout and set the render state accurately. - Use
ShaderVariantCollection.Warmup
orShader.WarmupAllShaders
, which may create inaccurate prewarmed GPU representations because you can’t provide a vertex data layout or render state.
Control how much memory shaders use
In your built application, Unity stores several ‘chunks’ of compressed shader variant data. Each chunk contains multiple shader variants. When Unity loads a scene at runtime, it loads all the scene’s chunks into CPU memory and decompresses them.
To reduce memory usage on platforms that have limited memory, you can limit the size of chunks and how many decompressed chunks Unity keeps in memory.
To do this, in Player settings
, select Other Settings > Shader Variant Loading and adjust the following settings:
- Use Default chunk size (MB) to set the maximum size of compressed chunks Unity stores in your built application.
- Use Default chunk count to limit how many decompressed chunks Unity keeps in memory. The default is
0
, which means there’s no limit.
See PlayerSettings.SetDefaultShaderChunkCount for more information.
You can use Override to override the values for each platform individually. See PlayerSettings.SetShaderChunkCountForPlatform for more information.
You can also use Shader.maximumChunksOverride to override Default chunk count at runtime.
Profiler markers for shader loading
You can use the following profiler markers
to see shader loading in the Profiler
:
Shader.ParseThreaded
andShader.ParseMainThread
for Unity loading the shader object from serialized data.Shader.CreateGPUProgram
for Unity creating a GPU-specific version of a shader variant.
/
Shader.CreateGPUProgram
该API常常在渲染模块主函数的堆栈中出现,并造成渲染模块中的大多数函数峰值。它是Shader第一次渲染时产生的耗时,其耗时与渲染Shader的复杂程度相关。当它在游戏过程中被调用并且造成较高的耗时峰值时应引起注意。
对此,我们可以将Shader通过ShaderVariantCollection收集要用到的变体并进行AssetBundle打包。在将该ShaderVariantCollection资源加载进内存后,通过在游戏前期场景调用ShaderVariantCollection.WarmUp来触发Shader.CreateGPUProgram,并将此SVC进行缓存,从而避免在游戏运行时触发此API的调用、避免局部的CPU高耗时。
然而即便是已经做过以上操作的项目也常会检测到运行时偶尔的该API耗时峰值,说明存在一些“漏网之鱼”。开发者可以结合Profiler的Timeline模式,选中触发调用Shader.CreateGPUProgram的帧来查看具体是哪些Shader触发了该API,可以参考。
timeline里可以看到具体开销,但量比较多的时候一帧里找还是挺费劲的。
对于漏网之鱼的定位,后来还介绍了一种方法,我实际了一下记录一下:
就是启用 LogShaderCompilation 功能:
打开 Unity 编辑器,并打开您的项目。
在菜单栏中选择 "Edit"(编辑)选项。
在下拉菜单中选择 "Project Settings"(项目设置)。
在 "Project Settings"(项目设置)窗口中,选择 "Graphics"(图形)选项卡。
在 "Graphics"(图形)选项卡中,找到 "Shader Loading"部分。将 "LogShaderCompilation"(当着色器编译时记录日志)选项勾选上。
打包在手机上运行后, 用logcat抓到日志
关键字 Compiled shader, Debug级别的,如果你过滤了可能看不到。
看一下日志能看到当时哪个shader 的什么Keywords触发了编译
///