In this article, we are going to explore the topic of High-Level Shader Language in a deep and detailed manner. _Var1 has been a topic of interest and debate for a long time, and in this article, we are going to examine its origins, its impact on society, and its relevance in today's world. From its beginnings to its evolution over the years, High-Level Shader Language has been a fundamental element in multiple aspects of daily life. We will analyze different points of view, investigate relevant data, and present opinions from experts in the field. With an objective and critical approach, this article seeks to shed light on High-Level Shader Language and its influence on the modern world.
| Cg/HLSL | |
|---|---|
A scene containing several different 2D HLSL shaders. Distortion of the statue is achieved purely physically, while the texture of the rectangular frame beside it is based on color intensity. The square in the background has been transformed and rotated. The partial transparency and reflection of the water in the foreground are added by a shader applied finally to the entire scene. | |
| Family | shading language |
| Developer | nVIDIA, Microsoft |
| Dialects | |
| Cg, HLSL, Playstation Shading Language, ReShadeFX, Slang | |
| Influenced by | |
| C, RenderMan Shading Language | |
| Influenced | |
| GLSL | |
The High-Level Shader Language[1] or High-Level Shading Language[2] (HLSL) is a proprietary shading language developed by Microsoft for the Direct3D 9 API to augment the shader assembly language, and went on to become the required shading language for the unified shader model of Direct3D 10 and higher. It was developed alongside the Cg (short for C for Graphics) shading language from Nvidia. Early versions of the two languages were considered identical, only marketed differently.[3]
Although Cg and HLSL share the same core syntax, some features of C were modified and new data types were added to make Cg/HLSL more suitable for programming graphics processing units.[4][5]
Two main branches of the Cg/HLSL language exist: the Nvidia Cg compiler (cgc) which outputs DirectX or OpenGL and the Microsoft HLSL which outputs DirectX shaders in bytecode format.[6][7] Nvidia's cgc was deprecated in 2012, with no additional development or support available.[8]
HLSL shaders can enable many special effects in both 2D and 3D computer graphics.
D3D11.3 and D3D12 introduced Shader Model 5.1[10] and later 6.0.[11]
Due to technical advances in graphics hardware, some areas of 3D graphics programming have become quite complex. To simplify the process, new features were added to graphics cards, including the ability to modify their rendering pipelines using vertex and pixel shaders.
In the beginning, vertex and pixel shaders were programmed at a very low level with only the assembly language of the graphics processing unit. Although using the assembly language gave the programmer complete control over code and flexibility, it was fairly hard to use. A portable, higher level language for programming the GPU was needed, so Cg was created to overcome these problems and make shader development easier.
Some of the benefits of using Cg/HLSL over assembly are:
Cg/HLSL has six basic data types. Some of them are the same as in C, while others are especially added for GPU programming. These types are:
Cg also features vector and matrix data types that are based on the basic data types, such as float3 and float4x4. Such data types are quite common when dealing with 3D graphics programming. Cg also has struct and array data types, which work in a similar way to their C equivalents.
Cg supports a wide range of operators, including the common arithmetic operators from C, the equivalent arithmetic operators for vector and matrix data types, and the common logical operators.
Cg shares the basic control structures with C, like if/else, while, and for. It also has a similar way of defining functions.
Cg implements many C preprocessor directives and its macro expansion system. It implements #include.[12]
Cg programs are built for different shader profiles that stand for GPUs with different capabilities.[13] These profiles decide, among others, how many instructions can be in each shader, how many registers are available, and what kind of resources a shader can use. Even if a program is correct, it might be too complex to work on a profile.[12]
As the number of profile and shader types cropped up, Microsoft has switched to use the term "Shader Model" to group a set of profiles found in a generation of GPUs.[14] Cg supports some of the newer profiles up to Shader Model 5.0 as well as translation to glsl or hlsl.[13]
GPUs listed are the hardware that first supported the given specifications. Manufacturers generally support all lower shader models through drivers. Note that games may claim to require a certain DirectX version, but don't necessarily require a GPU conforming to the full specification of that version, as developers can use a higher DirectX API version to target lower-Direct3D-spec hardware; for instance DirectX 9 exposes features of DirectX7-level hardware that DirectX7 did not, targeting their fixed-function T&L pipeline.
| Pixel shader version | 1.0 | 1.1 | 1.2
1.3[15] |
1.4[15] | 2.0[15][16] | 2.0a[15][16][17] | 2.0b[15][16][18] | 3.0[15][19] | 4.0[20] 4.1[21]
5.0[22] |
|---|---|---|---|---|---|---|---|---|---|
| Dependent texture limit | 4 | 4 | 4 | 6 | 8 | Unlimited | 8 | Unlimited | Unlimited |
| Texture instruction limit | 4 | 4 | 4 | 6 * 2 | 32 | Unlimited | Unlimited | Unlimited | Unlimited |
| Arithmetic instruction limit | 8 | 8 | 8 | 8 * 2 | 64 | Unlimited | Unlimited | Unlimited | Unlimited |
| Position register | No | No | No | No | No | No | No | Yes | Yes |
| Instruction slots | 8 | 8 + 4 | 8 + 4 | (8 + 6) * 2 | 64 + 32 | 512 | 512 | ≥ 512 | ≥ 65536 |
| Executed instructions | 8 | 8 + 4 | 8 + 4 | (8 + 6) * 2 | 64 + 32 | 512 | 512 | 65536 | Unlimited |
| Texture indirections | 4 | 4 | 4 | 4 | 4 | Unlimited | 4 | Unlimited | Unlimited |
| Interpolated registers | 2 + 4 | 2 + 4 | 2 + 4 | 2 + 6 | 2 + 8 | 2 + 8 | 2 + 8 | 10 | 32 |
| Instruction predication | No | No | No | No | No | Yes | No | Yes | No |
| Index input registers | No | No | No | No | No | No | No | Yes | Yes |
| Temp registers | 2 | 2 + 4 | 3 + 4 | 6 | 12 to 32 | 22 | 32 | 32 | 4096 |
| Constant registers | 8 | 8 | 8 | 8 | 32 | 32 | 32 | 224 | 16×4096 |
| Arbitrary swizzling | No | No | No | No | No | Yes | No | Yes | Yes |
| Gradient instructions | No | No | No | No | No | Yes | No | Yes | Yes |
| Loop count register | No | No | No | No | No | No | No | Yes | Yes |
| Face register (2-sided lighting) | No | No | No | No | No | No | Yes | Yes | Yes |
| Dynamic flow control | No | No | No | No | No | No | No | Yes (24) | Yes (64) |
| Bitwise Operators | No | No | No | No | No | No | No | No | Yes |
| Native Integers | No | No | No | No | No | No | No | No | Yes |
"32 + 64" for Executed Instructions means "32 texture instructions and 64 arithmetic instructions."
| Vertex shader version | 1.0 | 1.1[23] | 2.0[16][23][17] | 2.0a[16][23][17] | 3.0[19][23] | 4.0[20] 4.1[21] 5.0[22] |
|---|---|---|---|---|---|---|
| # of instruction slots | 128 | 128 | 256 | 256 | ≥ 512 | ≥ 65536 |
| Max # of instructions executed | 128 | 128 | 1024 | 65536 | 65536 | Unlimited |
| Instruction predication | No | No | No | Yes | Yes | Yes |
| Temp registers | 12 | 12 | 12 | 16 | 32 | 4096 |
| # constant registers | ≥ 96 | ≥ 96 | ≥ 256 | 256 | ≥ 256 | 16×4096 |
| Address register | No | Yes | Yes | Yes | Yes | Yes |
| Static flow control | No | No | Yes | Yes | Yes | Yes |
| Dynamic flow control | No | No | No | Yes | Yes | Yes |
| Dynamic flow control depth | — | — | — | 24 | 24 | 64 |
| Vertex texture fetch | No | No | No | No | Yes | Yes |
| # of texture samplers | — | — | — | — | 4 | 128 |
| Geometry instancing support | No | No | No | No | Yes | Yes |
| Bitwise operators | No | No | No | No | No | Yes |
| Native integers | No | No | No | No | No | Yes |
As in C, Cg/HLSL features a set of functions for common tasks in GPU programming. Some of the functions have equivalents in C, like the mathematical functions abs and sin, while others are specialized in GPU programming tasks, like the texture mapping functions tex1D and tex2D.
Cg/HLSL programs are merely vertex and pixel shaders, and they need supporting programs that handle the rest of the rendering process. Cg can be used with two graphics APIs: OpenGL or DirectX. Each has its own set of Cg functions to communicate with the Cg program, like setting the current Cg shader, passing parameters, and such tasks. (HLSL only targets DirectX.)
In addition to being able to compile Cg source to assembly code, the Cg runtime also has the ability to compile shaders during execution of the supporting program. This allows the runtime to compile the shader using the latest optimizations available for hardware that the program is currently executing on. However, this technique requires that the source code for the shader be available in plain text to the compiler, allowing the user of the program to access the source-code for the shader. Some developers view this as a major drawback of this technique.
To avoid exposing the source code of the shader, and still maintain some of the hardware specific optimizations, the concept of profiles was developed. Shaders can be compiled to suit different graphics hardware platforms (according to profiles). When executing the supporting program, the best/most optimized shader is loaded according to its profile. For instance there might be a profile for a graphics card that supports complex pixel shaders, and another profile for one that supports only minimal pixel shaders. By creating a pixel shader for each of these profiles a supporting program enlarges the number of supported hardware platforms without sacrificing picture quality on powerful systems.'
The Cg dialect has only ever had one compiler, in the form of Nvidia's Cg toolkit.
Microsoft has released two compilers for HLSL. The original compiler was the closed-source FXC (Effect Compiler), supported until 2015. It was deprecated in favor of the open-source LLVM-based DXC (DirectXShaderCompiler) with support for newer HLSL features.[24] Both compilers generate bytecode: while the older FXC used DXBC, DXC now uses DXIL. DXC can also emit SPIR-V bytecode.[25]
The Khronos Group has also written a LLVM-based HLSL compiler, in the form of a frontend for glslang, their GLSL-to-SPIR_V compiler. Support for SPIR-V means that the shaders can be cross-platform, no longer limiting them to a DirectX stack.[26] This task was previously performed by source-level converters like HLSL2GLSL, but the resulting code is often bloated.[27]
The PlayStation Shader Language (PSSL) is based on Cg/HLSL.[28]
The ReshadeFX shading language is also based on Cg/HLSL. Shaders written in ReshadeFX are compiled to OpenGL, DX, or Vulkan and injected into games to act as post-processing filters.[29]
Khronos has since evolved glslang into slang, a shading language and compiler that is mostly source-code-compatible with HLSL. Slang can compile to textual shading languages (GLSL, MSL, CUDA, WGSL), bytecodes (D3D11, D3D12, Vulkan SPIR-V) as well as the CPU. It also has a GLSL-compatibility mode.[30]