Hubbry Logo
ShaderShaderMain
Open search
Shader
Community hub
Shader
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Shader
Shader
Shader
View on Wikipedia
from Wikipedia

A simplified illustration of the graphics pipeline in the Vulkan API. The yellow sections are programmable shader stages which can modify the different data being processed by the pipeline.

In computer graphics, a shader is a programmable operation which is applied to data as it moves through the rendering pipeline.[1][2] Shaders can act on data such as vertices and primitives — to generate or morph geometry — and fragments — to calculate the values in a rendered image.[2]

Shaders can execute a wide variety of operations and can run on different types of hardware. In modern real-time computer graphics, shaders are run on graphics processing units (GPUs) — dedicated hardware which provides highly parallel execution of programs. As rendering an image is embarrassingly parallel, fragment and pixel shaders scale well on SIMD hardware. Historically, the drive for faster rendering has produced highly-parallel processors which can in turn be used for other SIMD amenable algorithms.[3] Such shaders executing in a compute pipeline are commonly called compute shaders.

History

[edit]

The first known use of the term "shader" was introduced to the public by Pixar with version 3.0 of their RenderMan Interface Specification, originally published in May 1988.[4]

As graphics processing units evolved, major graphics software libraries such as OpenGL and Direct3D began to support shaders. The first shader-capable GPUs only supported pixel shading, but vertex shaders were quickly introduced once developers realized the power of shaders. The first video card with a programmable pixel shader was the Nvidia GeForce 3 (NV20), released in 2001.[5] Geometry shaders were introduced with Direct3D 10 and OpenGL 3.2. Eventually, graphics hardware evolved toward a unified shader model.

Graphics shaders

[edit]

The traditional use of shaders is to operate on data in the graphics pipeline to control the rendering of an image. Graphics shaders can be classified according to their position in the pipeline, the data being manipulated, and the graphics API being used.

Fragment shaders

[edit]
The Stanford dragon model rendered using fragment shaders with different outputs: solid white, applied texture, physically based shading.

Fragment shaders, also known as pixel shaders, compute color and other attributes of each "fragment": a unit of rendering work affecting at most a single output pixel. The simplest kinds of pixel shaders output one screen pixel as a color value; more complex shaders with multiple inputs/outputs are also possible.[6] Pixel shaders range from simply always outputting the same color, to applying a lighting value, to doing bump mapping, shadows, specular highlights, translucency and other phenomena. They can alter the depth of the fragment (for Z-buffering), or output more than one color if multiple render targets are active. In 3D graphics, a pixel shader alone cannot produce some kinds of complex effects because it operates only on a single fragment, without knowledge of a scene's geometry (i.e. vertex data). However, pixel shaders do have knowledge of the screen coordinate being drawn, and can sample the screen and nearby pixels if the contents of the entire screen are passed as a texture to the shader. This technique can enable a wide variety of two-dimensional postprocessing effects such as blur, or edge detection/enhancement for cartoon/cel shaders. Pixel shaders may also be applied in intermediate stages to any two-dimensional images—sprites or textures—in the pipeline, whereas vertex shaders always require a 3D scene. For instance, a pixel shader is the only kind of shader that can act as a postprocessor or filter for a video stream after it has been rasterized.

Vertex shaders

[edit]

Vertex shaders are run once for each 3D vertex given to the graphics processor. The purpose is to transform each vertex's 3D position in virtual space to the 2D coordinate at which it appears on the screen (as well as a depth value for the Z-buffer).[7] Vertex shaders can manipulate properties such as position, color and texture coordinates, but cannot create new vertices. The output of the vertex shader goes to the next stage in the pipeline, which is either a geometry shader if present, or the rasterizer. Vertex shaders can enable powerful control over the details of position, movement, lighting, and color in any scene involving 3D models.

Geometry shaders

[edit]

Geometry shaders were introduced in Direct3D 10 and OpenGL 3.2; formerly available in OpenGL 2.0+ with the use of extensions.[8] This type of shader can generate new graphics primitives, such as points, lines, and triangles, from those primitives that were sent to the beginning of the graphics pipeline.[9]

Geometry shader programs are executed after vertex shaders. They take as input a whole primitive, possibly with adjacency information. For example, when operating on triangles, the three vertices are the geometry shader's input. The shader can then emit zero or more primitives, which are rasterized and their fragments ultimately passed to a pixel shader.

Typical uses of a geometry shader include point sprite generation, geometry tessellation, shadow volume extrusion, and single pass rendering to a cube map. A typical real-world example of the benefits of geometry shaders would be automatic mesh complexity modification. A series of line strips representing control points for a curve are passed to the geometry shader and depending on the complexity required the shader can automatically generate extra lines each of which provides a better approximation of a curve.

Tessellation shaders

[edit]

As of OpenGL 4.0 and Direct3D 11, a new shader class called a tessellation shader has been added. It adds two new shader stages to the traditional model: tessellation control shaders (also known as hull shaders) and tessellation evaluation shaders (also known as Domain Shaders), which together allow for simpler meshes to be subdivided into finer meshes at run-time according to a mathematical function. The function can be related to a variety of variables, most notably the distance from the viewing camera to allow active level-of-detail scaling. This allows objects close to the camera to have fine detail, while further away ones can have more coarse meshes, yet seem comparable in quality. It also can drastically reduce required mesh bandwidth by allowing meshes to be refined once inside the shader units instead of downsampling very complex ones from memory. Some algorithms can upsample any arbitrary mesh, while others allow for "hinting" in meshes to dictate the most characteristic vertices and edges.

Primitive and Mesh shaders

[edit]

Circa 2017, the AMD Vega microarchitecture added support for a new shader stage—primitive shaders—somewhat akin to compute shaders with access to the data necessary to process geometry.[10][11]

Nvidia introduced mesh and task shaders with its Turing microarchitecture in 2018 which are also modelled after compute shaders.[12][13] Nvidia Turing is the world's first GPU microarchitecture that supports mesh shading through DirectX 12 Ultimate API, several months before Ampere RTX 30 series was released.[14]

In 2020, AMD and Nvidia released RDNA 2 and Ampere microarchitectures which both support mesh shading through DirectX 12 Ultimate.[15] These mesh shaders allow the GPU to handle more complex algorithms, offloading more work from the CPU to the GPU, and in algorithm intense rendering, increasing the frame rate of or number of triangles in a scene by an order of magnitude.[16] Intel announced that Intel Arc Alchemist GPUs shipping in Q1 2022 will support mesh shaders.[17]

Ray tracing shaders

[edit]

Ray tracing shaders are supported by Microsoft via DirectX Raytracing, by Khronos Group via Vulkan, GLSL, and SPIR-V,[18] by Apple via Metal. NVIDIA and AMD called "ray tracing shaders" as "ray tracing cores". Unlike unified shader, one ray tracing shader can contain multiple ALUs.[19]

Compute shaders

[edit]

Compute shaders are not limited to graphics applications, but use the same execution resources for GPGPU. They may be used in graphics pipelines e.g. for additional stages in animation or lighting algorithms (e.g. tiled forward rendering). Some rendering APIs allow compute shaders to easily share data resources with the graphics pipeline.

Tensor shaders

[edit]

Tensor shaders may be integrated in NPUs or GPUs. Tensor shaders are supported by Microsoft via DirectML, by Khronos Group via OpenVX, by Apple via Core ML, by Google via TensorFlow, by Linux Foundation via ONNX.[20] NVIDIA and AMD called "tensor shaders" as "tensor cores". Unlike unified shader, one tensor shader can contains multiple ALUs.[21]

Programming

[edit]
Main article: Shading language

Several programming languages exist specifically for writing shaders, and which is used can depend on the target environment. The shading language for OpenGL is GLSL, and Direct3D uses HLSL. The Metal framework, used by Apple devices, has its own shading language called Metal Shading Language.

Increasingly in modern graphics APIs, shaders are compiled into SPIR-V, an intermediate language, before they are distributed to the end user. This standard allows more flexible choice of shading language, regardless of target platform.[22] First supported by Vulkan and OpenGL, SPIR-V is also being adopted by Direct3D.[23]

GUI shader editors

[edit]

Modern video game development platforms such as Unity, Unreal Engine and Godot increasingly include node-based editors that can create shaders without the need for written code; the user is instead presented with a directed graph of connected nodes that allow users to direct various textures, maps, and mathematical functions into output values like the diffuse color, the specular color and intensity, roughness/metalness, height, normal, and so on. The graph is then compiled into a shader.

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Shader

View on Grokipedia
from Grokipedia
In , a shader is a small, executable program designed to run on a (GPU), performing parallel computations to manipulate during the , such as transforming vertices, applying effects, and determining colors to generate visual output. Shaders are essential components of the modern , enabling the creation of realistic textures, shadows, reflections, and other effects in real-time applications like video games, simulations, and . The concept originated in the early 1980s at , where procedural shading techniques were developed for high-end film production using custom software on supercomputers. Programmable shaders for consumer hardware emerged in 2000 with Microsoft's 8, introducing vertex and shaders, followed by OpenGL extensions like ARB_vertex_program in 2002 that brought similar capabilities to the cross-platform API. Over time, shader functionality expanded with and geometry stages in 10 (2006) and 3.2 (2009), and compute shaders in 11 (2009) and 4.3 (2012) for general-purpose GPU computing beyond traditional rendering. Shaders operate at specific stages of the and are categorized by their roles: vertex shaders process input vertices to compute positions and attributes like normals; tessellation control and evaluation shaders subdivide patches for detailed surface ; geometry shaders generate or modify primitives from input ; fragment shaders (or pixel shaders) compute the final color and depth for each rasterized fragment; and compute shaders handle non-graphics tasks like simulations or data processing in parallel workgroups. They are authored in high-level shading languages, such as the Shading Language (GLSL) for and APIs, or High-Level Shading Language (HLSL) for , both of which resemble C and support vector mathematics, textures, and uniform variables for efficient GPU execution. Modern advancements, including ray-tracing support in shader model 6.0 ( 12 Ultimate, 2020) and mesh shaders in extensions (2022), continue to enhance shader versatility for photorealistic and performant rendering, with recent developments like neural shaders in 12 (as of 2025) enabling AI-driven rendering techniques.

Fundamentals

Definition

A shader is a compact program executed on the (GPU) to perform specialized computations on graphics data as part of the rendering process. These programs enable flexible processing of visual elements, distinguishing them from earlier hardware-limited approaches by allowing custom logic to be applied directly on the GPU hardware. The primary purposes of shaders include transforming vertex positions in 3D space, determining colors and effects, generating additional , and supporting general-purpose computations beyond traditional rendering. Key characteristics encompass their implementation in high-level shading languages, parallel execution across the GPU's numerous cores to handle massive workloads efficiently, and a design that is stateless—meaning no persistent state is maintained between invocations—and intended to produce deterministic results for consistent rendering, though practical variations may occur due to . In contrast to fixed-function pipeline stages, which rely on predefined hardware operations for tasks like transformation and , programmable shaders provide developer-defined behavior at these stages, enhancing versatility in graphics rendering. The basic execution model involves shaders processing individual graphics , such as vertices or fragments, using inputs like per-primitive attributes (e.g., position or texture coordinates) and uniforms (constant parameters shared across invocations), with outputs directed to render targets like buffers or the .

Graphics Pipeline Integration

The in modern GPU architectures processes 3D scene data through a sequence of fixed-function and programmable stages to produce a final 2D image on the screen. Key stages include the input assembler, which assembles vertices from buffers; vertex processing, where positions and attributes are transformed; primitive assembly, which forms geometric like triangles; rasterization, which converts into fragments; fragment , where colors are computed; and the output merger, which blends results into render targets. Shaders integrate into the pipeline's programmable stages—such as vertex and fragment —replacing earlier fixed-function hardware units that handled rigid operations like basic transformations and . This shift to programmability, which began with 8 in 2000 and OpenGL extensions in 2001, was advanced in APIs like 10 (2006) and 2.0 (2004), allowing developers to implement custom algorithms for effects including physically based , dynamic texturing, and advanced shading models, enhancing visual realism and artistic control. Data flows sequentially through the with inputs comprising vertex attributes (e.g., positions, normals) from index and vertex buffers, uniform variables for global parameters like matrices, and textures accessed via samplers. Inter-stage communication occurs through varying qualifiers, where outputs from the vertex stage—such as transformed positions in clip space and interpolated attributes—are passed to the fragment stage after rasterization. Final outputs include fragment colors and depth values directed to framebuffers or other render targets in the output merger. In graphics APIs, pipeline configuration involves compiling shader code into modules and binding them to specific stages via pipeline state objects (PSOs) or equivalent structures, such as 12's ID3D12PipelineState or Vulkan's VkPipeline. requires allocating and binding buffers for vertex data, constant buffers for uniforms, and descriptor sets or tables for textures and samplers, ensuring shaders can access them during execution without runtime overhead. This shader-driven architecture provides key benefits, including the ability to realize complex effects like procedural geometry generation within vertex stages and real-time ray tracing extensions through dedicated shader invocations, far surpassing the limitations of fixed-function pipelines in supporting diverse rendering techniques.

History

Origins and Early Concepts

The origins of in trace back to the 1970s, when researchers developed mathematical models to simulate surface and enhance the realism of rendered images. , introduced in 1971, represented an early approach to smooth by interpolating colors across vertices, thereby avoiding the faceted appearance of flat while computing only at vertices for efficiency. This technique prioritized computational feasibility on early hardware, laying groundwork for methods. Shortly after, in 1975, proposed a more sophisticated reflection model that separated illumination into ambient, diffuse, and specular components, enabling per-pixel normal to capture highlights and surface details more accurately than vertex-based methods. These models established as a core concept for local illumination, influencing subsequent hardware and software developments despite their initial software-only implementation. In the 1980s, advancements in rendering architectures began to integrate shading concepts into production pipelines, particularly for film and animation. At (later ), the REYES (Render Everything Really Easy) architecture, developed by , Loren Carpenter, and Robert L. Cook, introduced micropolygon-based rendering around 1980, where complex surfaces were subdivided into tiny polygons shaded individually to support and . This system optimized shading for high-quality output by processing micropolygons in screen space, serving as a precursor to parallel graphics processing and influencing hardware design. Building on REYES, released RenderMan in 1988, a commercial rendering system that included the first for procedural surface effects, allowing artists to define custom illumination models beyond fixed mathematics. These innovations met the growing demand for photorealistic visuals in films like (1995), but remained software-bound, highlighting the need for . The saw the shift to dedicated graphics hardware with fixed-function , which hardcoded stages for , texturing, and transformation to accelerate real-time rendering in and simulations. Cards like the Voodoo (1996) implemented multi-texturing and basic in fixed stages, enabling rasterization without CPU intervention, though limited to predefined operations like Gouraud-style . Similarly, NVIDIA's (1997) featured a configurable with four texture units for effects such as environment mapping, but remained non-programmable, relying on driver-set parameters for custom looks. These systems dominated consumer graphics, processing billions of pixels per second, yet their rigidity constrained complex effects, prompting multi-pass techniques to approximate advanced . Rising demands for custom effects in mid-1990s films—such as procedural textures in RenderMan for (1993)—and video games—like dynamic in Quake (1996)—exposed limitations of fixed hardware, driving early experiments in low-level GPU programming via assembly-like instructions to tweak combiners and registers. This pressure culminated in a key milestone with NVIDIA's in 1999, the first consumer GPU to integrate dedicated transform and (T&L) engines, offloading vertex shading from the CPU and hinting at future programmability through hardware-accelerated fixed stages.

Evolution in Graphics APIs

The evolution of shader programmability in graphics APIs began in 2000 with Microsoft's 8, which introduced vertex and shaders. Hardware support followed in 2001 with GPUs such as NVIDIA's GeForce 3 and ATI's Radeon 8500, enabling programming in and marking a shift from fixed-function pipelines to basic programmable stages. This enabled developers to customize transformations and per-pixel operations beyond rigid hardware limitations, laying the groundwork for more expressive rendering techniques. Programmable shaders initially used low-level assembly-like instructions via extensions like ARB_vertex_program (2001) and ARB_fragment_program (2002). High-level shading languages emerged from 2002 to 2004, with Microsoft's High-Level Shading Language (HLSL) debuting with 9 in 2002, supporting shader model 2.0 for improved precision and branching, and (GLSL) introduced alongside OpenGL 2.0 in 2004 for more accessible vertex and fragment programming. OpenGL 2.0 in 2004 and 9's shader model 3.0 further standardized these capabilities, allowing longer programs and dynamic branching for complex effects like procedural textures. The mid-2000s saw expanded shader stages, as DirectX 10 in 2006 added geometry shaders to process primitives after vertex shading, enabling amplification and simplification of geometry on the GPU. DirectX 11 in 2009 introduced tessellation shaders for adaptive subdivision and compute shaders for general-purpose GPU computing, with OpenGL 3.2 in 2009 adding tessellation shaders and OpenGL 4.3 in 2012 introducing compute shaders to align cross-platform development. In the 2010s, modern APIs focused on efficiency and low-level control, with Apple's Metal API released in 2014 emphasizing streamlined shader pipelines for iOS and macOS devices to reduce overhead in draw calls. Vulkan, launched in 2016 by the Khronos Group, extended this with explicit resource management and SPIR-V as an intermediate representation for portable shaders across APIs. Microsoft's DirectX 12, introduced in 2015, built on these principles with enhanced command list handling for shaders, paving the way for advanced features like mesh shaders in later updates. By 2018, real-time ray tracing gained traction through extensions like (DXR) in 12 and Vulkan's ray tracing extension (VK_KHR_ray_tracing_pipeline), integrating specialized shaders for ray generation, intersection, and to simulate interactions more accurately. shaders arrived in 12 Ultimate in 2020, replacing and stages with a unified task/mesh pipeline for scalable geometry processing, followed by 1.3 in 2022 for broader adoption. The SPIR-V format, adopted from 2016, has facilitated cross-API shader portability by compiling high-level code to a binary intermediate language. As of 2025, no major new core shader types have been introduced in primary APIs, though integration of AI-accelerated —using neural networks for denoising and upscaling in ray-traced pipelines—has proliferated, as seen in NVIDIA's DLSS and AMD's FSR implementations.

Graphics Shaders

Vertex Shaders

Vertex shaders operate on individual vertices early in the , transforming their positions from model to clip space through matrix multiplications, typically involving the model, view, and projection matrices to prepare for rasterization. This stage performs per-vertex computations such as coordinate transformations, normal vector adjustments, and texture coordinate generation, ensuring that subsequent stages receive properly oriented vertex data. The inputs to a vertex shader include per-vertex attributes supplied from vertex buffers, such as position, normal vectors, and UV texture coordinates, along with variables like transformation matrices and lighting parameters that remain constant across vertices in a draw call. Texture samplers can be accessed in vertex shaders for operations like displacement mapping, though this is rarely utilized due to hardware limitations in earlier shader models and the efficiency of handling such computations in later stages. Outputs from the vertex shader consist of the transformed vertex position, written to a built-in variable such as gl_Position in GLSL or SV_Position in HLSL, which defines the clip-space coordinates for primitive assembly. Additionally, varying outputs—such as interpolated normals, colors, or texture coordinates—are passed to the next stage for interpolation across , enabling smooth effects without per-vertex redundancy. Vertex shaders execute once per input vertex, immediately following the input assembler and preceding primitive assembly in the rendering , which allows for efficient parallel processing on the GPU as each invocation is independent. This model ensures a one-to-one mapping between input and output vertices, preserving the of the input . Common applications of vertex shaders extend beyond basic transformations to include skeletal , where vertex positions are blended using influence matrices to animate character meshes in real-time. Procedural deformations, such as wind-driven animations for vegetation, leverage vertex shaders to apply dynamic offsets based on time or noise functions, simulating natural motion without CPU intervention. effects, used for particles or distant objects, orient vertices to always face the camera by replacing the model matrix with a view-dependent transformation in the shader.

Fragment Shaders

Fragment shaders, also known as pixel shaders in some APIs, are a programmable stage in the responsible for processing each fragment generated by rasterization to determine its final , and other attributes. These shaders execute after the rasterization stage, where primitives are converted into fragments representing potential pixels, and before the per-fragment operations like depth testing and blending. The primary function is to compute the appearance of each fragment based on interpolated from earlier stages, enabling per-fragment effects that contribute to realistic rendering. Inputs to a fragment shader include interpolated varying variables from the vertex shader, such as texture coordinates, surface normals, and positions, which are automatically interpolated across the primitive by the rasterizer. Additionally, uniforms provide constant data like light positions, material properties, and transformation matrices, while texture samplers allow access to bound textures for sampling color or other data at specific coordinates. These inputs enable the shader to perform computations tailored to each fragment's position and attributes without accessing vertex-level data directly. The outputs of a fragment shader typically include one or more color values written to the , often via built-in variables like gl_FragColor in GLSL or explicit output locations in modern languages. Optionally, shaders can modify the fragment's depth value using gl_FragDepth for custom depth computations or discard fragments entirely to simulate effects like alpha testing. values can also be altered if enabled, though this is less common. These outputs are then subjected to fixed-function tests and blending before final composition. Common applications of fragment shaders include texture mapping, where interpolated UV coordinates are used to sample from textures and combine them with base colors, and lighting calculations to simulate illumination per fragment. For instance, the Phong reflection model computes intensity as the sum of ambient, diffuse, and specular components: I=Iaka+Idkd(N⋅L)+Isks(R⋅V)nI = I_a k_a + I_d k_d (\mathbf{N} \cdot \mathbf{L}) + I_s k_s (\mathbf{R} \cdot \mathbf{V})^n where IaI_a, IdI_d, and IsI_s are ambient, diffuse, and specular light intensities; kak_a, kdk_d, and ksk_s are material coefficients; N\mathbf{N} is the surface normal; L\mathbf{L} is the light direction; R\mathbf{R} is the reflection vector; V\mathbf{V} is the view direction; and nn is the shininess exponent. This model, originally proposed by Bui Tuong Phong, is widely implemented in fragment shaders for efficient per-pixel lighting. Other uses encompass fog effects, achieved by blending fragment colors toward a fog color based on depth or distance, and contributions to anti-aliasing through techniques like multisample anti-aliasing (MSAA) integration or post-processing filters that smooth edges by averaging samples. Fragment shaders are executed once per fragment in a highly parallel manner across the GPU, making them performance-critical due to their impact on fill rate—the number of fragments processed per second. Modern GPUs optimize this by executing shaders on streaming multiprocessors or compute units, with early rejection via depth or tests to avoid unnecessary computations. Complex shaders can become bottlenecks in scenes with high overdraw, emphasizing the need for efficient code to maintain frame rates.

Geometry Shaders

Geometry shaders represent an optional programmable stage in the graphics rendering pipeline, positioned immediately after the vertex shader and prior to the rasterization stage. This stage enables developers to process entire input primitives—such as points, lines, or triangles—allowing for the generation of new primitives or the modification of existing ones directly on the GPU. Introduced in 10 with Shader Model 4.0 in November 2006, geometry shaders marked a significant advancement in GPU programmability by extending beyond per-vertex operations to per-primitive processing. incorporated geometry shaders in version 3.2, released in August 2009, aligning with the core profile to support modern hardware features. The primary function of a geometry shader is to receive a complete primitive from the vertex shader output, including its topology (e.g., GL_TRIANGLES or GL_POINTS in OpenGL) and associated per-vertex attributes such as positions, normals, and texture coordinates. Unlike vertex shaders, which handle individual vertices independently, geometry shaders operate on the full set of vertices defining the primitive, providing access to inter-vertex relationships for more sophisticated manipulations. This enables tasks like transforming the primitive's shape or topology while preserving or augmenting vertex data. In the OpenGL Shading Language (GLSL), inputs are accessed via built-in arrays like gl_in, which holds the vertex data for the current primitive. Similarly, in High-Level Shading Language (HLSL) for Direct3D, the shader receives the primitive's vertices through input semantics defined in the shader signature. Outputs from geometry shaders are generated dynamically by emitting new vertices and completing primitives, subject to hardware-imposed limits on amplification. In GLSL, developers use the EmitVertex() function to append a vertex (with current output variable values) to the ongoing primitive, followed by EndPrimitive() to finalize and emit the primitive to subsequent pipeline stages. This allows for variable output topologies, such as converting a point primitive into a for billboard rendering. In HLSL, equivalent functionality is achieved through [maxvertexcount(N)] declarations, where N specifies the maximum vertices per invocation, capped by hardware constraints like 1024 scalar components per primitive in 10-era implementations—translating to an effective amplification factor of up to approximately 32 times for typical vertex formats (e.g., position and color). Beyond scalar limits, outputs must adhere to supported topologies like point lists, line strips, or , ensuring compatibility with rasterization. Common applications of geometry shaders leverage their primitive-level control for efficient geometry generation and optimization. For instance, point primitives can be extruded into billboard quads to render particle effects or impostors, where a single input point expands into four vertices forming a textured square always facing the camera. Fur or hair simulation often employs geometry shaders to generate strand-like line strips from base mesh edges, creating dense fibrous surfaces without excessive CPU-side geometry preparation. Shadow volume creation benefits from on-the-fly extrusion of silhouette edges into volume primitives, streamlining real-time lighting computations in deferred rendering pipelines. Additionally, primitive culling can be implemented by conditionally discarding or simplifying input primitives based on visibility criteria, such as frustum or occlusion tests, reducing downstream workload. These uses highlight geometry shaders' role in balancing performance and visual fidelity in real-time graphics.

Tessellation Shaders

Tessellation shaders enable adaptive subdivision of coarse patches into finer meshes on the GPU, facilitating detailed surface rendering without excessive vertex data in . In the , they operate after the vertex shader stage and consist of two programmable components: the hull shader (also known as the tessellation control shader in ) and the domain shader (tessellation evaluation shader). The hull shader processes input control points from patches, such as Bézier curves or surfaces, to generate output control points and compute tessellation factors that dictate subdivision density. These factors include edge levels for patch boundaries and inside levels for interior subdivision, typically ranging from 1 to 64, allowing control over the level of detail (LOD) based on factors like viewer distance to optimize performance. The fixed-function hardware tessellator then uses these factors to generate a denser grid of vertices from the patch topology, evaluating parametric coordinates (e.g., u-v parameters for Bézier patches) without programmable intervention. The domain shader subsequently receives these generated vertices, along with the original control points and tessellation factors, to displace or position them in world space, often applying height or displacement maps for realistic surface variations. This produces a stream of dense vertices that feeds into subsequent stages, such as the shader or rasterizer, enabling techniques like for enhanced detail. Introduced in 11 in 2009 and 4.0 in 2010, tessellation shaders integrate post-vertex processing to dynamically adjust complexity, reducing CPU-side vertex generation while leveraging GPU parallelism. Common applications include terrain rendering, where tessellation factors vary with distance to create seamless transitions across landscapes; character skinning, which uses subdivision for smooth, wrinkle-free deformations; and approximation of subdivision surfaces like Catmull-Clark, where low-order Bézier patches represent higher-order geometry for efficient rendering of complex models. These uses exploit the hardware tessellator's efficiency in evaluating subdivision patterns, allowing real-time adaptation to viewing conditions without precomputing all possible detail levels.

Mesh Shaders

Mesh shaders represent a significant evolution in graphics pipeline stages, combining and replacing the traditional vertex, geometry, and tessellation shaders with a more flexible, compute-like model for geometry processing. Introduced as part of DirectX 12 Ultimate, they enable developers to generate variable numbers of vertices and primitives directly within the shader, bypassing fixed-function topology constraints and reducing overhead from multiple pipeline stages. This approach leverages workgroups to process meshlets—small, efficient units of geometry—allowing for dynamic culling, amplification, and generation of mesh data on the GPU. The primary function of mesh shaders involves two complementary stages: the task shader (also known as the amplification shader) and the shader itself. The task shader operates on input workgroups, performing or amplification to determine the number of meshlets needed, outputting a variable count of child workgroups to invoke mesh shaders. The mesh shader then executes within these workgroups, generating vertices, indices, and primitive data for each meshlet, which are directly fed into the rasterizer without intermediate fixed-function processing. This task-based processing model allows for coarse-grained decisions at the task stage and fine-grained vertex/primitive assembly at the mesh stage, streamlining workloads. Inputs to mesh shaders typically originate from draw calls that specify groups of meshlets, along with per-meshlet attributes, uniform buffers, and resources such as textures or buffers for . These inputs are processed cooperatively within a workgroup, similar to compute shaders, enabling access and thread for efficient data handling. Outputs from a single mesh shader invocation include a variable number of vertices (up to 256) and (up to 512 per meshlet), defined in one of three modes: points, lines, or triangles, which replaces the rigid of traditional pipelines and supports dynamic topologies without additional writes. Common applications of mesh shaders include efficient level-of-detail (LOD) management, where task shaders can cull distant or occluded before ; procedural mesh creation for complex scenes like terrain or foliage; and building ray-tracing acceleration structures by generating custom on-the-fly. By consolidating multiple shader stages into these programmable units, mesh shaders reduce pipeline bubbles—idle periods between stages—and improve GPU utilization, particularly for high-vertex-count models, leading to performance gains in scenarios with variable complexity. Mesh shaders were first introduced in 12 Ultimate in March 2020, with initial hardware support on 's Turing architecture (RTX 20-series and later), though broader adoption accelerated with the RTX 30-series and subsequent generations. In , support arrived via the VK_EXT_mesh_shader extension in 2022, enabling cross-platform implementation on compatible hardware from , (RDNA 2 and later), and . This replacement of legacy stages has been adopted in modern engines for rasterization pipelines, offering up to 2x performance improvements in geometry-heavy workloads by minimizing draw call overhead and enabling better parallelism.

Ray-Tracing Shaders

Ray-tracing shaders represent a specialized class of programmable shaders designed to simulate light paths in real-time rendering by tracing rays through a scene. Introduced in major APIs such as (DXR) in 2018 and Ray Tracing extensions in 2020, these shaders enable developers to implement physically accurate effects by querying ray intersections against scene geometry. Unlike traditional rasterization-based shading, ray-tracing shaders operate on ray queries, allowing for dynamic computation of light interactions without relying on fixed screen-space sampling. They are typically integrated into hybrid rendering pipelines that combine rasterization for primary visibility with ray tracing for secondary effects, often employing denoising techniques to achieve interactive frame rates on hardware-accelerated GPUs. The primary shader types in ray-tracing pipelines include ray-generation, miss, closest-hit, any-hit, and callable shaders, each serving distinct roles in processing ray queries. The ray-generation shader acts as the , dispatched in a grid similar to compute shaders, where it defines ray origins and directions based on screen pixels or other sources and initiates tracing via calls like TraceRayInline or TraceRay. Miss shaders execute when a ray does not intersect any , commonly used to sample environment maps or compute background contributions for effects like sky lighting. Closest-hit shaders run upon detecting the nearest , retrieving hit attributes such as barycentric coordinates, world position, surface normal, and material properties to perform calculations, such as diffuse or specular responses. Any-hit shaders handle potential intersections for non-opaque surfaces, evaluating transparency or alpha testing to accept or reject hits, often in scenarios involving blended materials. Callable shaders provide a mechanism for indirect invocation from other shaders via the CallShader intrinsic, enabling modular reuse of for complex procedural evaluations without full ray tracing. These shaders receive inputs including ray origins and directions, acceleration structures for efficient traversal—such as bottom-level structures (BLAS) for individual meshes and top-level structures (TLAS) for instanced scenes using hierarchies (BVH)—and scene data like textures or materials bound via descriptor heaps. Outputs consist of hit attributes passed back through the and shading results written to a ray-tracing output buffer, which may include color payloads or visibility flags for further processing. Common applications encompass to simulate indirect bounces, realistic reflections on glossy surfaces, and soft shadows by tracing occlusion rays, frequently in hybrid setups where rasterized provides base and ray tracing enhances details like caustics or . Performance optimizations, such as denoising passes on noisy ray-traced samples, are essential for real-time viability in these uses. Execution of ray-tracing shaders occurs through dispatch commands, such as DispatchRays in DXR or traceRaysKHR in , which launch the ray-generation shader grid and traverse the acceleration structure hardware-accelerated by dedicated RT cores on GPUs introduced in 2018. Intersection tests are offloaded to these cores for and triangle checks, while shading remains on general-purpose streaming multiprocessors. for multiple bounces is managed via a hardware stack, limiting depth to prevent excessive , with payloads propagated between shader invocations to accumulate lighting contributions across the ray path. This model supports scalable parallelism, where thousands of rays are processed concurrently to render complex scenes at interactive rates.

Compute Shaders

Core Functionality

Compute shaders enable general-purpose computing on processing units (GPUs) by decoupling from the traditional , allowing developers to perform arbitrary parallel computations. Unlike shaders tied to fixed stages, compute shaders operate as standalone kernels dispatched across a grid of threads organized into workgroups, supporting one-, two-, or three-dimensional layouts for scalable . This flexibility permits execution on thousands of GPU threads simultaneously, leveraging the massive inherent in modern GPUs without the constraints of vertex or fragment rasterization. Compute shaders were first introduced in 11 in 2009 by , expanding GPU capabilities beyond to general-purpose tasks. In terms of execution, a compute shader is invoked via API calls such as glDispatchCompute in or Dispatch in , specifying the number of workgroups along each dimension of the grid. Each workgroup consists of multiple threads that execute the shader code cooperatively, enabling efficient handling of data-parallel workloads. The shader code, written in languages like GLSL or HLSL, defines the logic, with built-in variables like gl_GlobalInvocationID providing unique identifiers for each thread to access input data and determine output positions. This model supports highly scalable operations, where the GPU scheduler distributes threads across available cores, achieving performance gains for tasks involving large datasets. Compute shaders access inputs through shader storage buffer objects (SSBOs), image textures, and uniform buffers, which provide read/write access to large data structures on the GPU. Within a workgroup, threads can share data via declared variables, facilitating intra-group communication and reducing global memory traffic. Outputs are written back to SSBOs or s, allowing results to be used in subsequent computations or transferred to the CPU. For , functions like memoryBarrierShared() in GLSL ensure that shared memory writes are visible to other threads before proceeding, preventing race conditions in cooperative algorithms. These mechanisms enable atomic operations and barriers to coordinate thread execution within workgroups. Common applications of compute shaders in general-purpose GPU (GPGPU) computing include particle simulations, where threads update positions and velocities for thousands of particles in parallel; physics computations such as N-body simulations modeling gravitational interactions via the force equation F=Gm1m2r2,F = G \frac{m_1 m_2}{r^2}, where GG is the , m1m_1 and m2m_2 are masses, and rr is the distance between bodies; image processing tasks like convolutions for filters such as blurring or ; and fast Fourier transforms (FFTs) for signal analysis. These uses exploit the GPU's parallel architecture to accelerate simulations that would be computationally intensive on CPUs, often achieving real-time performance for complex datasets.

Tensor and Specialized Shaders

Tensor and specialized shaders represent an evolution of compute shaders tailored for accelerating tensor operations, particularly in workloads. These shaders execute optimized kernels that perform matrix and tensor mathematics, exploiting specialized hardware units such as tensor cores to achieve high throughput via (SIMD) processing. Introduced with NVIDIA's Volta architecture in 2017, Tensor Cores enable mixed-precision computations that significantly boost performance for tasks compared to general-purpose cores. Similarly, AMD's CDNA architecture incorporates Matrix Cores to deliver comparable acceleration for AI and applications. The primary inputs to these shaders consist of tensor buffers in low-precision formats like FP16 or INT8, along with weights and biases, which are loaded into GPU memory for efficient access. These formats reduce demands while maintaining sufficient numerical accuracy for many AI models. Outputs are typically transformed tensors, such as feature activations following convolutional or fully connected layers, which can be passed to subsequent shader invocations or used in broader stages. This design facilitates seamless integration into end-to-end workflows, where data flows through multiple tensor operations without host intervention. In practice, tensor and specialized shaders are commonly deployed for machine learning inference and training, with a focus on general matrix multiply (GEMM) operations of the form C=A×BC = A \times B for matrices AA and BB. NVIDIA Tensor Cores, for instance, execute these as fused multiply-accumulate instructions on 4x4 FP16 matrices, delivering up to 125 TFLOPS of throughput on Volta-based GPUs like the Tesla V100. AMD Matrix Cores support analogous operations through matrix fused multiply-add (MFMA) instructions, optimized for wavefront-level parallelism in CDNA GPUs such as the Instinct MI series, enabling scalable performance for large-scale AI training. These hardware accelerations are pivotal for reducing training times in models like transformers, where GEMM dominates computational cost. Execution occurs by dispatching these shaders as compute kernels, incorporating tensor-specific intrinsics to directly target the underlying hardware. In NVIDIA's CUDA ecosystem, the Warp Matrix Multiply-Accumulate (WMMA) API provides programmatic access to Tensor Cores within compute shaders, allowing developers to fragment larger matrices into warp-synchronous operations. For GPU-agnostic environments, APIs like Vulkan expose cooperative matrix extensions (e.g., VK_KHR_cooperative_matrix) that enable tensor intrinsics in SPIR-V shaders, supporting cross-vendor hardware without low-level vendor specifics. Microsoft's DirectML further abstracts this by compiling high-level ML operators into DirectX 12 compute shaders, leveraging tensor cores on compatible GPUs for operator execution. Integration with frameworks such as TensorFlow and PyTorch occurs through backends like cuDNN (for NVIDIA) or ROCm (for AMD), which automatically dispatch these optimized shaders during graph execution, often with automatic mixed-precision to invoke tensor hardware transparently.

Programming Shaders

Languages and Syntax

Shader programming languages are high-level, C-like constructs designed for GPU execution, enabling developers to write code for graphics and compute pipelines. These languages share foundational syntax elements but differ in integration, type systems, and extensions tailored to specific hardware ecosystems. Major languages include GLSL for and , HLSL for , and MSL for Metal, with emerging standards like WGSL for addressing cross-platform needs. The (GLSL) is a C-like language used with and APIs, featuring versioned specifications up to 4.60 for desktop and 3.20 for embedded systems. It includes built-in types such as vec4 for 4-component vectors and mat4 for 4x4 matrices, facilitating vectorized operations essential for transformations. GLSL supports extensions like GL_ARB_compute_shader for compute shaders since version 4.30 and GLSL_EXT_ray_tracing for ray-tracing capabilities with extensions, allowing shaders to interface with advanced rendering pipelines. High-Level Shading Language (HLSL), developed by for , adopts a syntax similar to C++ and is used to program shaders across the pipeline. It incorporates an older effect framework via .fx files for encapsulating multiple techniques and passes, though modern usage favors standalone shader objects. HLSL provides intrinsics for (DXR), such as RayTracingAccelerationStructure, enabling ray-tracing shaders with functions like TraceRay. Shaders written in HLSL can be cross-compiled to SPIR-V intermediate representation using the DirectX Shader Compiler (DXC) for compatibility. Metal Shading Language (MSL), Apple's shading language for the Metal API, is based on a subset of C++11 and integrates seamlessly with Swift and Objective-C environments on iOS, macOS, and visionOS. It emphasizes strong static typing for type safety and performance, with features like constexpr for compile-time evaluation and automatic SIMD vectorization. MSL shaders declare inputs and outputs using attributes such as [[stage_in]] for vertex inputs and [[color(0)]] for fragment outputs, ensuring explicit resource binding. Across these languages, common syntax elements promote portability and efficiency on parallel GPU architectures. Inputs and outputs are declared with qualifiers like in and out in GLSL, or input and output semantics in HLSL, defining data flow between shader stages. Vector types, such as float3 in HLSL or vec3 in GLSL, support swizzling (e.g., pos.xyz) and component-wise operations for spatial computations. Control flow structures include if, for, and while statements, but implementations warn against branch divergence in SIMD execution to avoid performance penalties on GPU warps. Precision qualifiers, particularly in GLSL for (e.g., highp, mediump, lowp), allow optimization for mobile hardware by specifying floating-point accuracy. The Cg (C for ) language, jointly developed by and ATI from 2002 to 2012, was an early high-level modeled on with extensions for . It supported profiles for various APIs but has been deprecated since 2012, with recommending migration to GLSL or HLSL for ongoing development. An emerging language is WGSL (WebGPU Shading Language), first published in 2021 as part of the standard by the W3C and now at Recommendation status as of 2024, designed for secure, portable shader execution in web browsers. WGSL features Rust-inspired syntax with explicit types, structured bindings (e.g., @group(0) @binding(0) var<uniform> u : Uniform;), and no directives, prioritizing and validation over legacy C-style flexibility.

Compilation Process

Shader compilation transforms high-level shader , written in languages such as GLSL or HLSL, into executable suitable for GPU execution. This process can occur offline during the build phase or at runtime, depending on the graphics API and development workflow. Offline compilation pre-processes shaders to intermediate , reducing runtime overhead; for instance, GLSL source can be converted to SPIR-V using the glslangValidator tool provided in the SDK. Online compilation, in contrast, happens dynamically via API calls, allowing flexibility but potentially introducing performance costs. Intermediate representations (IRs) play a crucial role in ensuring portability and validation across hardware. SPIR-V, developed by the and finalized in version 1.0 in 2016, serves as the standard binary IR for and extensions in , enabling cross-vendor compatibility by abstracting hardware-specific details. Similarly, DXIL (DirectX Intermediate Language), introduced for 12, is an LLVM-based IR that represents shaders in a hardware-agnostic form, facilitating optimizations and validation before final code generation. These IRs allow drivers to perform hardware-specific translations while maintaining a standardized interchange format. During compilation, multiple optimization passes refine the shader code for efficiency. Common passes include , which removes unused instructions; , which precomputes constant expressions; and , which assigns variables to limited GPU registers to minimize spills. These optimizations occur in the front-end and middle-end of the compiler pipeline, often using infrastructure for both SPIR-V and DXIL. Driver vendors then apply additional, hardware-specific optimizations; for example, NVIDIA's Vulkan driver includes passes for SPIR-V control flow analysis and constant integer optimization to enhance performance on its GPUs. AMD drivers similarly incorporate register pressure management and instruction fusing tailored to its architectures, such as RDNA. At runtime, shaders are loaded into the GPU driver using API-specific functions. In , developers call glCreateShader to allocate a shader object, followed by glShaderSource to attach and glCompileShader to trigger compilation to . For , the D3DCompile or D3DCompileFromFile functions compile HLSL source directly to DXIL , which the driver then processes. To mitigate repeated compilations across sessions or device changes, drivers employ caching mechanisms; shader blobs or pipeline caches store compiled artifacts on disk, allowing reuse and avoiding full recompiles when hardware or drivers update. In , pipeline caches explicitly support this by serializing compilation results for incremental loading. Despite these efficiencies, shader compilation presents challenges, particularly with variant permutations arising from API feature levels, texture formats, or conditional branches, which can generate thousands of unique shader versions requiring separate compilation. In modern APIs like Vulkan, asynchronous compilation—where shaders are compiled in background threads to overlap with rendering—helps distribute the load but can still cause stuttering if pipelines are created just-in-time during gameplay. Techniques such as pre-caching common variants or using uber-shaders mitigate these issues by reducing the number of on-demand compilations.

Editing and Debugging Tools

Shader development relies on specialized tools for editing, testing, and debugging to streamline iteration in graphics pipelines. GUI-based shader editors provide intuitive interfaces for , particularly for fragment shaders in GLSL. Shadertoy is a web-based platform that enables live editing and execution of GLSL shaders directly in the browser, allowing users to create and share without local setup. It supports real-time previews and a community gallery of thousands of open-source examples, facilitating experimentation with and functions. Similarly, The Book of Shaders offers an interactive online tutorial system focused on fragment shaders, where users can edit GLSL code alongside immediate visual feedback to explore concepts like and patterns. For more structured editing, NVIDIA's Nsight Graphics enables dynamic text-based editing of shaders during debugging sessions for effects like ray tracing. Integrated Development Environments (IDEs) enhance shader writing through syntax support and integration with graphics APIs. provides native HLSL support via its Shader Designer, a graphical tool for creating and modifying shaders through a node-graph interface, compiling to effects files for applications. This includes preview rendering and parameter tweaking without full recompilation. For cross-platform work, extensions like ShadeView 2 offer comprehensive HLSL and GLSL support, including , auto-completion, live previews, and Unity integration for real-time shader testing. Another extension, the Shader languages support pack, provides basic for GLSL, HLSL, and CG, aiding code navigation in larger projects. Debugging shaders requires capturing and inspecting GPU execution to identify issues like incorrect outputs or performance bottlenecks. RenderDoc is a widely used open-source tool for frame capture across APIs like Vulkan, OpenGL, and DirectX, enabling detailed shader inspection by stepping through invocations, viewing inputs/outputs per pixel or thread, and editing resources on-the-fly. NVIDIA Nsight Graphics offers advanced GPU debugging, including warp-level analysis to trace thread divergence and memory accesses in shaders, with support for real-time breakpoints and variable watches in HLSL or GLSL code. For AMD hardware, the Radeon GPU Profiler (RGP) captures traces to debug shader pipelines, correlating events with CPU timelines and inspecting assembly for issues in compute or graphics shaders. Intel's Graphics Performance Analyzers (GPA) provide cross-API debugging, allowing frame analysis and shader disassembly to pinpoint errors in execution flow. Profiling tools measure key shader metrics to optimize , focusing on factors like execution and utilization. Common metrics include shader invocations, which count how many times a shader executes per frame to assess overdraw; register usage, where high counts reduce GPU by limiting parallel warps; and , measuring inefficiency in SIMD execution that serializes threads. Tools like Nsight quantify these via GPU traces, showing warp stalls from in ray-tracing shaders. RGP reports register pressure and invocation counts for pipeline bottlenecks, while GPA offers unified metrics across vendors for comparing overhead. Best practices in shader development emphasize iterative workflows to minimize . Hot-reloading enables seamless updates by compiling shaders in a background thread and swapping pipelines without restarting the application, as implemented in and engines to accelerate prototyping. can leverage compute shaders to isolate and verify logic, such as rendering test patterns to buffers and comparing outputs against expected values for functions like matrix transformations. As of 2025, emerging AI-assisted tools are gaining traction; for instance, integrations in use AI to generate and modify OSL shaders from prompts, automating boilerplate code while preserving customizability. These practices, combined with the referenced tools, support efficient during the compilation process by allowing quick validation of shader variants.

References

  1. https://www.cs.vu.nl/~eliens/download/literatuur-shaders.pdf
  2. https://registry.khronos.org/vulkan/specs/1.3/html/chap9.html
  3. https://developer.nvidia.com/blog/advanced-api-performance-shaders/
  4. https://developer.nvidia.com/blog/shader-debugging-made-easy-with-nvidia-nsight-graphics/
  5. https://openglbook.com/chapter-0-preface-what-is-opengl.html
  6. https://registry.khronos.org/OpenGL/extensions/ARB/ARB_vertex_program.txt
  7. https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.50.pdf
  8. https://www.khronos.org/news/press/khronos-releases-opengl-3-2-third-major-opengl-release-within-twelve-months
  9. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/hlsl-shader-model-5-1-features-for-direct3d-12
  10. https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.60.pdf
  11. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl
  12. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/hlsl-shader-model-6-0-features-for-direct3d-12
  13. https://www.khronos.org/blog/mesh-shading-for-vulkan
  14. https://developer.nvidia.com/blog/nvidia-rtx-advances-with-neural-rendering-and-digital-human-technologies-at-gdc-2025/
  15. https://learn.microsoft.com/en-us/visualstudio/designers/working-with-shaders?view=vs-2022
  16. https://learn.microsoft.com/en-us/windows/win32/direct3d12/pipelines-and-shaders-with-directx-12
  17. https://learn.microsoft.com/en-us/windows/win32/direct3d11/direct3d-11-advanced-stages-compute-shader
  18. https://developer.nvidia.com/gpugems/gpugems2/part-ii-shading-lighting-and-shadows/chapter-17-efficient-soft-edged-shadows-using
  19. https://learn.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-graphics-pipeline
  20. https://learn.microsoft.com/en-us/windows/win32/direct3d10/d3d10-graphics-programming-guide-pipeline-stages
  21. https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.1.10.pdf
  22. https://registry.khronos.org/vulkan/specs/1.3-extensions/html/chap10.html
  23. https://dl.acm.org/doi/10.1145/360825.360839
  24. https://graphics.pixar.com/library/Reyes/paper.pdf
  25. https://ethw.org/Milestones:The_Development_of_RenderMan%25C2%25AE_for_Photorealistic_Graphics%2C_1981-1988
  26. https://mcclanahoochie.com/blog/wp-content/uploads/2011/03/gpu-hist-paper.pdf
  27. https://www.engr.colostate.edu/~sudeep/wp-content/uploads/CDA.11-P374493.pdf
  28. https://developer.download.nvidia.com/assets/gamedev/docs/TransformAndLighting.pdf
  29. https://learn.microsoft.com/en-us/archive/msdn-magazine/2014/september/directx-factor-vertex-shaders-and-transforms
  30. https://learn.microsoft.com/en-us/windows/uwp/graphics-concepts/graphics-pipeline
  31. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-writing-shaders-9
  32. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-to-sample
  33. https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.60.html
  34. https://learn.microsoft.com/en-us/windows/win32/direct3d11/vertex-shader-stage
  35. https://learn.microsoft.com/en-us/windows/uwp/graphics-concepts/vertex-shader-stage--vs-
  36. https://developer.nvidia.com/gpugems/gpugems/part-i-natural-effects/chapter-3-skin-dawn-demo
  37. https://developer.nvidia.com/gpugems/gpugems3/part-iii-rendering/chapter-16-vegetation-procedural-animation-and-shading-crysis
  38. https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-1-toward-photorealism-virtual-botany
  39. https://learnopengl.com/Getting-started/Shaders
  40. https://learnopengl.com/Lighting/Basic-Lighting
  41. https://developer.nvidia.com/gpugems/gpugems/part-v-performance-and-practicalities/chapter-28-graphics-pipeline-performance
  42. https://theswissbay.ch/pdf/Gentoomen%2520Library/Game%2520Development/Programming/Microsoft%2520DirectX%252010%2520Technical%2520Brief.pdf
  43. http://www.opengl.org/registry/doc/glspec32.core.20090803.pdf
  44. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-geometry-shader
  45. https://developer.nvidia.com/gpugems/gpugems3/part-vi-gpu-computing/chapter-41-using-geometry-shader-compact-and-variable-length
  46. https://developer.arm.com/documentation/100587/0101/Geometry-shaders/An-example-use-for-geometry-shaders
  47. https://www.rastergrid.com/blog/2010/02/instance-culling-using-geometry-shaders/
  48. https://learn.microsoft.com/en-us/windows/win32/direct3d11/direct3d-11-advanced-stages-tessellation
  49. https://www.nvidia.com/content/gtc-2010/pdfs/2227_gtc2010.pdf
  50. https://developer.download.nvidia.cn/assets/gamedev/files/sdk/11/TerrainTessellation_WhitePaper.pdf
  51. https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.00.pdf
  52. https://developer.nvidia.com/gpugems/gpugems2/part-i-geometric-complexity/chapter-7-adaptive-tessellation-subdivision-surfaces
  53. https://www.microsoft.com/en-us/research/wp-content/uploads/2010/05/MSR-TR-2010-163.pdf
  54. https://devblogs.microsoft.com/directx/coming-to-directx-12-mesh-shaders-and-amplification-shaders-reinventing-the-geometry-pipeline/
  55. https://microsoft.github.io/DirectX-Specs/d3d/MeshShader.html
  56. https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/
  57. https://devblogs.microsoft.com/directx/announcing-microsoft-directx-raytracing/
  58. https://www.khronos.org/blog/vulkan-ray-tracing-final-specification-release
  59. https://learn.microsoft.com/en-us/windows/win32/direct3d12/direct3d-12-raytracing-hlsl-shaders
  60. https://microsoft.github.io/DirectX-Specs/d3d/Raytracing.html
  61. https://developer.nvidia.com/blog/introduction-nvidia-rtx-directx-ray-tracing/
  62. https://vulkan.lunarg.com/doc/view/1.4.309.0/windows/antora/spec/latest/chapters/raytracing.html
  63. https://developer.nvidia.com/blog/ray-tracing-in-unreal-engine-4-top-10-developer-questions/
  64. https://www.khronos.org/news/press/khronos-releases-opengl-4.3-specification-with-major-enhancements
  65. https://registry.khronos.org/OpenGL/specs/gl/GLSLangSpec.4.30.pdf
  66. https://www.cg.tuwien.ac.at/courses/Realtime/repetitorium/VU.WS.2014/rtr_rep_2014_ComputeShader.pdf
  67. https://learn.microsoft.com/en-us/windows/win32/direct3d12/multi-engine-n-body-gravity-simulation
  68. https://eliemichel.github.io/LearnWebGPU/basic-compute/image-processing/convolution-filters.html
  69. https://github.com/bane9/OpenGLFFT
  70. https://images.nvidia.com/content/volta-architecture/pdf/volta-architecture-whitepaper.pdf
  71. https://www.amd.com/content/dam/amd/en/documents/instinct-business-docs/white-papers/amd-cdna-white-paper.pdf
  72. https://docs.nvidia.com/cuda/volta-tuning-guide/index.html
  73. https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-matrix-cores-readme/
  74. https://developer.nvidia.com/blog/programming-tensor-cores-cuda-9/
  75. https://learn.microsoft.com/en-us/windows/ai/directml/dml
  76. https://developer.nvidia.com/blog/automatic-mixed-precision-the-turbo-charging-feature-for-faster-ai/
  77. https://developer.apple.com/metal/Metal-Shading-Language-Specification.pdf
  78. https://www.w3.org/TR/WGSL/
  79. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-pguide
  80. https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-language-syntax
  81. https://developer.download.nvidia.com/cg/Cg_language.html
  82. https://vulkan.lunarg.com/doc/view/latest/windows/spirv_toolchain.html
  83. https://registry.khronos.org/OpenGL-Refpages/gl4/html/glCreateShader.xhtml
  84. https://registry.khronos.org/SPIR-V/specs/unified1/SPIRV.html
  85. https://github.com/microsoft/DirectXShaderCompiler/wiki/FAQ
  86. https://www.research.ed.ac.uk/files/56917122/A_Cross_platform_Evaluation_of_Graphics_Shader_Compiler_Optimization.pdf
  87. https://github.com/Microsoft/DirectXShaderCompiler/blob/main/docs/DXIL.rst
  88. https://developer.nvidia.com/vulkan-driver
  89. https://gpuopen.com/learn/amd-lab-notes/amd-lab-notes-register-pressure-readme/
  90. https://learn.microsoft.com/en-us/windows/win32/direct3d11/how-to--compile-a-shader
  91. https://microsoft.github.io/DirectX-Specs/d3d/ShaderCache.html
  92. https://therealmjp.github.io/posts/shader-permutations-part1/
  93. https://github.com/godotengine/godot/issues/61233
  94. https://vulkan-tutorial.com/Drawing_a_triangle/Graphics_pipeline_basics/Shader_modules
  95. http://thebookofshaders.com/
  96. https://developer.nvidia.com/nsight-graphics
  97. https://learn.microsoft.com/en-us/visualstudio/designers/shader-designer?view=vs-2022
  98. https://marketplace.visualstudio.com/items?itemName=awwsky.shadeview
  99. https://marketplace.visualstudio.com/items?itemName=slevesque.shader
  100. https://www.intel.com/content/www/us/en/docs/gpa/user-guide/2024-2/optimize-shaders.html
  101. https://antongerdelan.net/opengl/shader_hot_reload.html
  102. https://frguthmann.github.io/posts/compute_shaders/
  103. https://www.autodesk.com/autodesk-university/class/Using-AI-for-the-Creation-and-Modification-of-OSL-Shaders-in-3ds-Max-2025
Add your contribution
Related Hubs
User Avatar
No comments yet.