Shader Compilation Target Levels

When writing either Surface ShadersUnity’s code generation approach that makes it much easier to write lit shaders than using low level vertex/pixel shader programs. More info
See in Glossary or regular Shader Programs, the HLSL source can be compiled into different “shaderA small script that contains the mathematical calculations and algorithms for calculating the Color of each pixel rendered, based on the lighting input and the Material configuration. More info
See in Glossary models”. To allow the use of more modern GPI functionality, you must use higher shader compilation targets.

Note: Using higher shader compilation targets may prevent the shader from working on older GPUs or platforms.

Indicate the compilation target by using the #pragma target name directive or the more specific #pragma require feature … directive. For example:

#pragma target 3.5
#pragma require integers 2darray instancing

Default compilation target

By default, Unity compiles shaders into almost the lowest supported target (“2.5”); in between DirectX shader models 2.0 and 3.0. Some other compilation directives make the shader automatically be compiled into a higher target:

Using a geometry shader (#pragma geometry) sets the compilation target to 4.0.
Using tessellation shaders (#pragma hull or #pragma domain) sets the compilation target to 4.6.

Any shader not explicitly setting a function entry point through #pragma for geometry, hull or domain shaders will downgrade internal shader capability requirements. This allows non-DX11 targets with broader run-time and feature differences to be more compatible with the existing shader content.

For example, Unity supports tessellation shaders on Metal graphics, but Metal doesn’t support geometry shaders. Using #pragma target 5.0 is still valid, as long as you don’t use geometry shaders.

Supported ‘#pragma target’ names

Here is the list of shader models supported, with roughly increasing set of capabilities (and in some cases higher platform/GPU requirements):

#pragma target 2.0

Works on all platforms supported by Unity. DX9 shader model 2.0.
Limited amount of arithmetic & texture instructions; 8 interpolators; no vertex texture sampling; no derivatives in fragment shadersThe “per-pixel” part of shader code, performed every pixel that an object occupies on-screen. The fragment shader part is usually used to calculate and output the color of each pixel. More info
See in Glossary; no explicit LODA system for building multiplayer capabilities for Unity games. It is built on top of the lower level transport real-time communication layer, and handles many of the common tasks that are required for multiplayer games. More info
See in Glossary texture sampling.

#pragma target 2.5 (default)

Almost the same as 3.0 target (see below), except still only has 8 interpolators, and does not have explicit LOD texture sampling.
Compiles into DX11 feature level 9.3 on Windows Phone.

#pragma target 3.0

DX9 shader model 3.0: derivative instructions, texture LOD sampling, 10 interpolators, more math/texture instructions allowed.
Not supported on DX11 feature level 9.x GPUs (e.g. most Windows Phone devices).
Might not be fully supported by some OpenGL ES 2.0 devices, depending on driver extensions present and features used.

#pragma target 3.5 (or es3.0)

OpenGL ES 3.0 capabilities (DX10 SM4.0 on D3D platforms, just without geometry shaders).
Not supported on DX11 9.x (WinPhone), OpenGL ES 2.0.
Supported on DX11+, OpenGL 3.2+, OpenGL ES 3+, Metal, Vulkan, PS4Sony’s eighth generation video game console.
See in Glossary/XB1 consoles.
Native integer operations in shaders, texture arrays and so on.

#pragma target 4.0

DX11 shader model 4.0.
Not supported on DX11 9.x (WinPhone), OpenGL ES 2.0/3.0/3.1, Metal.
Supported on DX11+, OpenGL 3.2+, OpenGL ES 3.1+AEP, Vulkan, PS4/XB1 consoles.
Has geometry shaders and everything that es3.0 target has.

#pragma target 4.5 (or es3.1)

OpenGL ES 3.1 capabilities (DX11 SM5.0 on D3D platforms, just without tessellation shaders).
Not supported on DX11 before SM5.0, OpenGL before 4.3 (i.e. Mac), OpenGL ES 2.0/3.0.
Supported on DX11+ SM5.0, OpenGL 4.3+, OpenGL ES 3.1, Metal, Vulkan, PS4/XB1 consoles.
Has compute shaders, random access texture writes, atomics and so on. No geometry or tessellation shaders.

#pragma target 4.6 (or gl4.1)

OpenGL 4.1 capabilities (DX11 SM5.0 on D3D platforms, just without compute shaders). This is basically the highest OpenGL level supported by Macs.
Not supported on DX11 before SM5.0, OpenGL before 4.1, OpenGL ES 2.0/3.0/3.1, Metal.
Supported on DX11+ SM5.0, OpenGL 4.1+, OpenGL ES 3.1+AEP, Vulkan, Metal (without geometry), PS4/XB1 consoles.

#pragma target 5.0

DX11 shader model 5.0.
Not supported on DX11 before SM5.0, OpenGL before 4.3 (i.e. Mac), OpenGL ES 2.0/3.0/3.1, Metal.
Supported on DX11+ SM5.0, OpenGL 4.3+, OpenGL ES 3.1+AEP, Vulkan, Metal (without geometry), PS4/XB1 consoles.

Note that all OpenGL-like platforms (including mobile) are treated as “capable of shader model 3.0”. WP8/WinRT platforms (DX11 feature level 9.x) are treated as only capable of shader model 2.5.

Supported ‘#pragma require’ names

List of supported feature names for the #pragma require directive:

interpolators10: At least 10 vertex-to-fragment interpolators (“varyings”) are available.
interpolators15: At least 15 vertex-to-fragment interpolators (“varyings”) are available.
interpolators32: At least 32 vertex-to-fragment interpolators (“varyings”) are available.
mrt4: Multiple Render Targets, at least 4.
mrt8: Multiple Render Targets, at least 8.
derivatives: PixelThe smallest unit in a computer image. Pixel size depends on your screen resolution. Pixel lighting is calculated at every screen pixel. More info
See in Glossary shader derivative instructions (ddx/ddy).
samplelod: Explicit texture LOD sampling (tex2Dlod / SampleLevel).
fragcoord: Pixel location (XY on screen, ZW depth in clip space) input in pixel shader.
integers: Integers are an actual data type, including bit/shift operations.
2darray: 2D texture arrays (Texture2DArray).
cubearray: CubemapA collection of six square textures that can represent the reflections in an environment or the skybox drawn behind your geometry. The six squares form the faces of an imaginary cube that surrounds an object; each face represents the view along the directions of the world axes (up, down, left, right, forward and back). More info
See in Glossary arrays (CubemapArray).
instancing: SV_InstanceID input system value.
geometry: DX10 geometry shaders.
compute: Compute shaders, structured buffers, atomic operations.
randomwrite: “random write” (UAV) textures.
tesshw: GPU support for hardware tessellation, but not necessarily tessellation shader stages (e.g. Metal supports tessellation, but not via shader stages).
tessellation: Tessellation hull/domain shader stages.
msaatex: Ability to access multi-sampled textures (Texture2DMS in HLSL).
sparsetex: Sparse textures with residency info (“Tier2” support in D3D terms; CheckAccessFullyMapped HLSL function). Note that currently this is only implemented on DX11/12.
framebufferfetch: Framebuffer fetch – ability to read input pixel color in the pixel shader.

The broad #pragma target directives are shorthands for the requirements above, and they correspond to:

2.5: derivatives
3.0: 2.5 + interpolators10 + samplelod + fragcoord
3.5: 3.0 + interpolators15 + mrt4 + integers + 2darray + instancing
4.0: 3.5 + geometry
5.0: 4.0 + compute + randomwrite + tesshw + tessellation
4.5: 3.5 + compute + randomwrite
4.6: 4.0 + cubearray + tesshw + tessellation

Note that in Direct3D terms shader model 4.0 also implies “mrt8”; and shader model 5.0 implies “interpolators32” and “cubearray”. However, these are not guaranteed to be available on many mobile platforms. So for backwards compatibility with existing shaders, writing #pragma target 4.0 does not automatically require 8 MRTs support; and writing #pragma target 5.0 does not require 32 interpolators nor cubemap arrays.

Unity Manual