Shader variants

Unity compiles your shaderA program that runs on the GPU. More info
See in Glossary source files into individual shader programs. Each compiled shader program has one or more variants. Variants are versions of the shader program that work with different combinations of shader keywords. At runtime, when Unity renders geometry, it uses the variant that matches the current requirements. For more information on how Unity loads and uses shader variants, see Shader loading.

Shader variants can improve performance, because they result in shader programs that contain only the code that is needed for the current material, at the current time. Common things to optimize in this way are texture reads, vertex inputs, interpolators, or complex code such as loops. Additionally, the shader programs themselves are smaller.

Shader variants can also improve your workflow, because they allow you to use the same shader source file in different ways. For example, you can configure settings for different materials, define functionality for different hardware, and dynamically change the behaviour of shaders at runtime.

However, there are potential downsides. It’s easy to create a very large number of variants, and this can result in the following:

• Increased build times, file sizes, runtime memory usage, and loading times.
• Greater complexity when manually preloading (“prewarming”) shaders.

In larger projects, these issues can lead to significant problems with performance and workflow. It is therefore very important to understand how shader variants work, and how to exclude (“strip”) unneeded variants from compilation.

Shaders with a very large number of variants are called “mega shaders” or “uber shaders”. Unity’s Standard Shader is an example of such a shader.

Number of shader variants

At build time, Unity compiles one set of shader variants for each graphics API for the current build target. The number of variants for each combination of graphics API and build target depends on your shader source files, and your use of shader keywords.

Graphics APIs

Unity compiles one set of shader variants for each graphics API in the list for the current build target. The shaders differ for each combination of build target and graphics API; for example, Unity compiles different shaders for Metal on iOSApple’s mobile operating system. More info
See in Glossary than for Metal on macOS.

Some shader programs or keywords might only target a given graphics API or a given build target, so the total number of variants for each combination of graphics API and build target can differ; however, the process for compiling these variants is the same.

To view and edit the list of graphics APIs for your current build target, use the Player SettingsSettings that let you set various player-specific options for the final game built by Unity. More info
See in Glossary window, or the PlayerSettings API.

Number of shader programs

Unity must determine how many shader programs to compile for the current combination of build target and graphics API.

For each shader source file that is included in your build, Unity determines how many unique shader programs it defines:

• A compute shader asset defines a single shader program.
• In a hand-coded shader, the number of shader programs depends on your code. The total comprises:
  • All shader stages in all Passes in the source file itself. For example, each vertex stage defines one shader program; each fragment stage defines one shader program; and so on.
  • All shader stages in all Passes in dependenciesIn the context of the Package Manager, a dependency is a specific package version (expressed in the form package_name@package_version) that a project or another package requires in order to work. Projects and packages use the dependencies attribute in their manifests to define the set of packages they require. For projects, these are considered direct dependencies; for packages, these are indirect, or transitive, dependencies. More info
    See in Glossary of the source file. This comprises all fallback shaders, and all Passes that are included using the UsePass command.
• In a Shader Graph shader, the number of shader programs depends on the code that Unity generates from your graph. To see the shader code that Unity generates, context-click the Shader Graph asset and select See generated code. You can then determine the total number of shader programs in the same way that you would for a hand-coded shader.

Note: A shader source file is included in a build if it is referenced in a sceneA Scene contains the environments and menus of your game. Think of each unique Scene file as a unique level. In each Scene, you place your environments, obstacles, and decorations, essentially designing and building your game in pieces. More info
See in Glossary in that build, referenced by something in the Resources folder, or included in the Always-included shaders section of the Graphics Settings window.

Keywords that affect a shader program

When Unity has determined how many shader programs it must compile for the current build target and graphics API, it then determines how many shader variants it must compile for each shader program.

For each shader program, Unity determines the combination of shader keywords that affect it. This comprises:

• The sets of shader keywords that are defined in the source file for that shader. For more information, see Declaring shader keywords.
• The sets of shader keywords that Unity adds automatically. For more information, see Unity’s predefined shader keywords.

The number of shader variants that Unity compiles for a shader program is the product of the keyword sets; that is to say, Unity compiles one variant for every combination that includes one element from each set.

For example, this set contains three keywords:

• COLOR_RED
• COLOR_GREEN
• COLOR_BLUE

This set contains four keywords:

• QUALITY_LOW
• QUALITY_MEDIUM
• QUALITY_HIGH
• QUALITY_ULTRA

A shader program affected by those keywords will result in the following twelve variants:

• COLOR_RED and QUALITY_LOW
• COLOR_RED and QUALITY_MEDIUM
• COLOR_RED and QUALITY_HIGH
• COLOR_RED and QUALITY_ULTRA
• COLOR_GREEN and QUALITY_LOW
• COLOR_GREEN and QUALITY_MEDIUM
• COLOR_GREEN and QUALITY_HIGH
• COLOR_GREEN and QUALITY_ULTRA
• COLOR_BLUE and QUALITY_LOW
• COLOR_BLUE and QUALITY_MEDIUM
• COLOR_BLUE and QUALITY_HIGH
• COLOR_BLUE and QUALITY_ULTRA

The number of variants that Unity compiles can grow very rapidly as you add more sets of keywords. For example, consider a fairly typical use case, where a shader has a number of sets of keywords that contain two keywords each (<feature name>_ON and <feature name>_OFF). If the shader has two such sets of keywords, this results in four variants. If the shader has ten such sets of keywords, this results in 1024 variants.

Deduplication of shader variants

After compilation, Unity automatically identifies identical variants within the same Pass, and ensures that these identical variants point to the same bytecode. This is called deduplication.

Deduplication prevents identical variants in the same Pass from increasing file size; however, identical variants still result in wasted work during compilation, and increased memory usage and shader loading times at runtime. With this in mind, it is always best to strip unneeded variants.

Stripping shader variants

You can prevent shader variants from being compiled. This is called stripping. Stripping unneeded variants can greatly reduce build times, file size, shader loading times, and runtime memory usage. In larger projects, or projects with complex shaders, this is a very important consideration.

Limiting shader variants when you declare shader keywords

The way that you declare shader keywords can limit the number of variants that they produce:

• Use shader_feature instead of multi_compile where possible.
• Ensure that you don’t define unused keywords with multi_compile.
• Indicate when shader keywords only affect a given shader stage.

For information on doing this in hand-coded shaders, see Declaring and using shader keywords in HLSL. For information on doing this in Shader Graph, see Shader Graph: Blackboard.

Stripping shader variants in the Editor UI

There are several places in the Unity Editor UI(User Interface) Allows a user to interact with your application. Unity currently supports three UI systems. More info
See in Glossary where you can configure shader stripping:

• In the Graphics Settings window, configure the settings in the Shader stripping section:
• Ensure that no unneeded shaders are included in the Always-included shaders setting.
• Strip variants relating to GPU instancing, lightmapping, and fog.
• In the Built-in Render PipelineA series of operations that take the contents of a Scene, and displays them on a screen. Unity lets you choose from pre-built render pipelines, or write your own. More info
  See in Glossary, if it is not important that your Tier settings are different, ensure that they are identical to each other. For more information, see Graphics tiers.
• In the Universal Render Pipeline (URP), disable unused features in the URP Asset. For more information, see Shader stripping.

Stripping shader variants using Editor scripts

For shader variants that you can’t strip in other ways, you can use the following APIs in an Editor script to perform build-time stripping:

• IPreprocessShaders.OnProcessShader: receive a callback before Unity compiles a graphics shader Pass into a build.
• IPreprocessComputeShaders.OnProcessComputeShader: receive a callback before Unity compiles a compute shader into a build.

For more information on this subject, see the Unity blog post Stripping scriptable shader variants