When writing either Surface Shaders or regular Shader Programs, the HLSL source can be compiled into different “shader 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
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:
#pragma geometry) sets the compilation target to 4.0.#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.
Here is the list of shader models supported, with roughly increasing set of capabilities (and in some cases higher platform/GPU requirements):
es3.0 target has.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.
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: Pixel 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: Cubemap 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: derivatives3.0: 2.5 + interpolators10 + samplelod + fragcoord3.5: 3.0 + interpolators15 + mrt4 + integers + 2darray + instancing4.0: 3.5 + geometry5.0: 4.0 + compute + randomwrite + tesshw + tessellation4.5: 3.5 + compute + randomwrite4.6: 4.0 + cubearray + tesshw + tessellationNote 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.