Graphics pipeline
More actions
A graphics pipeline (also called a rendering pipeline or graphics rendering pipeline) is the sequence of processing stages that a real-time rendering system uses to turn a description of a three-dimensional scene into a two-dimensional image. The fourth edition of the textbook Real-Time Rendering (2018), by Tomas Akenine-Möller, Eric Haines, Naty Hoffman and three co-authors, calls it "the core component of real-time graphics": its main function is to generate, or render, a two-dimensional image given a virtual camera, three-dimensional objects, light sources and more.[1] In the pipeline used by graphics processing units (GPUs), vertices are transformed and assembled into primitives such as triangles, the primitives are rasterized into fragments, the fragments are shaded, and the results are tested and blended into a framebuffer.[2]
The pipeline is defined by graphics APIs such as OpenGL, Direct3D and Vulkan. Early hardware implemented it as fixed-function circuitry. NVIDIA's GeForce 3 of 2001 introduced the first programmable vertex processor, and later GPUs made further stages programmable with small programs called shaders.[3]
Virtual reality (VR) and augmented reality (AR) headsets use the same pipeline but run it under extra constraints. Every frame has to be drawn from two viewpoints, pre-distorted for the headset's lenses, finished within one display refresh, and handed to a system compositor that handles distortion, prediction and synchronization before the image reaches the display. Several GPU and API features introduced for VR, such as multiview rendering, lens-matched shading and fragment density maps for foveated rendering, modify individual stages of the pipeline.[4][5][6]
How it works
Conceptual stages
Real-Time Rendering organizes its description of the pipeline into four functional stages: the application stage, geometry processing, rasterization and pixel processing.[1] The OpenGL 1.0 specification, by Mark Segal and Kurt Akeley and published by Silicon Graphics, describes the same flow. Commands are "effectively sent through a processing pipeline". In the stage that operates on geometric primitives, vertices "are transformed and lit, and primitives are clipped to a viewing volume in preparation for the next stage, rasterization". The rasterizer then produces fragments, and per-fragment operations decide how each fragment updates the framebuffer, including tests against stored depth values (depth buffering) and blending with stored colors. The specification adds that this ordering "is meant only as a tool for describing the GL, not as a strict rule of how the GL is implemented".[7] The Vulkan specification uses nearly the same words: commands are "effectively sent through a processing pipeline, such as a graphics pipeline".[2]
Stages in current APIs
Modern APIs split the pipeline into a mix of programmable shader stages and fixed-function stages. Microsoft describes the Direct3D 11 pipeline as "designed for generating graphics for realtime gaming applications"; it has the same stages as Direct3D 10 plus additional ones, and the stages built on common shader cores are programmed in the HLSL shading language.[8] The table compares the stage names in David Blythe's 2006 description of Direct3D 10 with the stage overview in the Vulkan specification.
| Function | Direct3D 10 stage[9] | Vulkan stage[2] | What happens |
|---|---|---|---|
| Vertex input | Input Assembler (IA) | Input assembly | Vertex data is read from buffers and assembled into points, lines and triangles. The Direct3D 10 IA can also replicate an object n times (instancing). |
| Vertex processing | Vertex Shader (VS) | Vertex shading | A program transforms each vertex, computing its position and other attributes. |
| Primitive processing | Geometry Shader (GS), Stream Output (SO) | Tessellation and geometry shading | Optional stages generate additional primitives from an input primitive; the Direct3D 10 SO stage copies vertex data to memory. |
| Rasterization | Set-up and Rasterization (RS) | Rasterization | A fixed-function stage converts each primitive into fragments. In Direct3D 10 it also handles clipping, culling, perspective divide, viewport transform, scissoring and depth offset. |
| Fragment processing | Pixel Shader (PS) | Fragment shading | A program determines the values, usually colors, to be written to the framebuffer attachments for each fragment. |
| Output | Output Merger (OM) | Fragment operations and framebuffer operations | Depth and stencil tests decide which fragments are kept, and colors are blended into the render targets. |
In Vulkan, a pipeline is controlled by "a monolithic object created from a description of all of the shader stages", which lets the implementation optimize the shaders together.[2] Blythe noted that GPUs also perform early depth rejection (z-cull or hierarchical z) inside the rasterization stage, an optimization that was "becoming less transparent to application developers".[9]
Newer APIs have added stages that change the front of the pipeline. In November 2019 Microsoft announced mesh shaders and amplification shaders for DirectX 12, which "will optionally replace the section of the pipeline" made up of the Input Assembler and the vertex, geometry, domain and hull shaders. A mesh shader uses a compute programming model and processes a mesh in parallel chunks called meshlets; Microsoft described the change as "reinventing the pipeline".[10] The Vulkan specification describes a parallel mesh pipeline in which primitives are "not assembled implicitly, but explicitly through the (Mesh Shader)", optionally preceded by a task shader.[2]
History
Special-purpose hardware
Ivan Sutherland's 1968 head-mounted display already used a hardware pipeline. In his paper on the system, Sutherland described how endpoints of lines were fetched from memory, transformed from room coordinates to eye coordinates by a special-purpose digital matrix multiplier, and passed to a digital "clipping divider", which eliminated "any information outside the user's field of view" and computed the perspective image. His team built this equipment because no available general-purpose computer was fast enough for a flicker-free dynamic picture; it could display 3,000 lines at 30 frames per second.[11]
James H. Clark's Geometry Engine, presented at SIGGRAPH 1982, put these geometric operations on a VLSI chip. Clark described it as "a four-component vector, floating-point processor" for three basic operations: matrix transformations, clipping, and mapping to output device coordinates. Twelve copies of the chip "arranged in a pipeline" formed the Geometry System, with matrix, clipping and scaling subsystems; its instruction set included perspective and orthographic projection and "stereo pair production".[12] According to Jon Peddie, the chip was developed by Clark and Marc Hannah at Stanford University in about 1981; Clark founded Silicon Graphics (SGI) the same year, and SGI's IRIS workstations used ten to twelve copies of the Geometry Engine.[13]
The OpenGL 1.0 specification from SGI drew the pipeline as a block diagram with an evaluator, per-vertex operations and primitive assembly, rasterization, per-fragment operations and the framebuffer, alongside display lists, pixel operations and texture memory. OpenGL 1.0 already supported stereo output, with "stereoscopic contexts" that contain both left and right color buffers.[7]
From fixed-function to programmable stages
NVIDIA engineers summarized the move from fixed-function hardware to programmable GPUs in a 2008 paper. The GeForce 256 of 1999 contained a fixed-function floating-point vertex transform and lighting processor and a fixed-function integer pixel-fragment pipeline. The GeForce 3 of 2001 introduced the first programmable vertex processor, and the Radeon 9700 of 2002 a programmable 24-bit floating-point pixel-fragment processor.[3] Erik Lindholm, Mark Kilgard and Henry Moreton described the GeForce 3 vertex engine at SIGGRAPH 2001: it "evolved from a highly tuned fixed-function pipeline", and its programs "operate only on a stream of independent vertices traversing the pipe", embedded in the broader fixed-function pipeline.[14]
Direct3D 10, described by Blythe in 2006, kept "the structure of the traditional hardware-accelerated 3D pipeline" but added two stages, the geometry shader and stream output. Blythe wrote that the previous five years had seen "the transition from a fixed-function pipeline to a programmable pipeline".[9] Hardware followed with unified shader processors. The Xbox 360 introduced an early unified GPU in 2005, and NVIDIA's Tesla architecture, introduced in the GeForce 8800 in November 2006, unified the vertex and pixel processors. The Tesla paper gives the reason: typical workloads were not balanced between vertices and pixels, so with large triangles the vertex processors sat mostly idle, and with small triangles the reverse happened.[3]
Later additions changed how much work each stage does rather than the order of the stages. Microsoft announced Variable Rate Shading for DirectX 12 in March 2019. Its "shading rate" is the resolution at which pixel shaders are called, separate from screen resolution; Tier 1 hardware sets the rate per draw call, and Tier 2 can vary it within a draw through a screen-space image or per primitive, which Microsoft listed as a way to implement foveated rendering.[15]
The pipeline in VR and AR
Frame loop and compositor
A VR application does not present its images to the display directly. In Valve's OpenVR API, the application calls WaitGetPoses to obtain the poses for rendering, renders the left and right eyes, and calls Submit to hand the undistorted textures to the compositor, which "simplifies the process of displaying images to the user by taking care of distortion, prediction, synchronization and other subtle issues".[16] The cross-vendor OpenXR standard has the same structure. Its xrWaitFrame function "throttles the application frame loop in order to synchronize application frame submissions with the display" and returns a predicted display time; the application brackets its GPU work with xrBeginFrame and xrEndFrame and submits composition layers. The specification says composition layers "allow an application to offload the composition of the final image to a runtime-supplied compositor", so that "frame-rate interpolation and distortion correction can be performed by the runtime".[17]
The compositor stage also separates VR from AR output. After blending and flattening all layers, the OpenXR compositor blends the image with the environment. VR applications generally choose the opaque blend mode, while AR applications generally choose additive or alpha blending.[17]
The time budget for the whole pipeline is set by the display. The HTC Vive developer edition discussed by Valve in 2015 refreshed at 90 Hz, which leaves 11.11 ms per frame.[4] The delay between a head movement and the matching change on screen is the motion-to-photon latency.
Two views per frame
Each eye needs its own image. In his 2015 talk, Valve's Alex Vlachos rated the options for a single GPU: running the CPU rendering code twice ("BAD"), amplifying geometry in a geometry shader ("BAD"), resubmitting command buffers ("GOOD", Valve's solution at the time) and using instancing to double the geometry ("BETTER", with half the API calls and improved cache coherency).[4]
Graphics APIs then added multiview rendering. The OpenGL extension OVR_multiview, whose contact is Cass Everitt of Oculus and whose contributors include John Carmack and engineers from companies including Qualcomm, NVIDIA, Google, Epic and ARM, notes that rendering the two eye buffers sequentially "typically incurs double the application and driver overhead". With the extension, draw calls are instanced into each element of a texture array, and the vertex program uses a gl_ViewID_OVR variable to compute per-view values such as the vertex position. The extension text anticipates that tile-based architectures "could sort geometry into tiles for multiple views in a single pass", and also anticipates rendering two views per eye, a wide one and a narrow inset, to keep sample density high in the center without oversampling the periphery.[5] Vulkan's VK_KHR_multiview extension has "the same goal", describes multiview as "a rendering technique originally designed for VR", and was promoted to core in Vulkan 1.1.[18]
Vendors added hardware and API support of their own. NVIDIA's Single Pass Stereo, which uses the Simultaneous Multi-Projection architecture of Pascal GPUs (GeForce GTX 1060 series and Quadro P4000 and higher), lets the GPU "draw geometry only once, then simultaneously project both right-eye and left-eye views".[19] Apple's Metal API offers vertex amplification, in which the GPU fetches vertex data once and calls the vertex function once per output, for example per texture layer or viewport.[20] On VisionOS, the Compositor Services framework offers a "layered" texture layout that stores each view's content as a slice of a single texture.[21] In Unity, single-pass instanced stereo renders the scene in one pass with instanced draw calls into a stereo texture array, which Unity says "significantly decreases CPU usage and slightly decreases GPU usage" compared with multi-pass rendering; multiview is a variation that replaces it on devices that support it.[22] See Stereoscopic rendering for the general technique.
Lens distortion
Headset lenses magnify the display and distort it, so a VR pipeline ends with an extra pass that pre-warps the image (lens distortion). In Valve's 2015 renderer, the warp pass used three sets of texture coordinates, one each for red, green and blue, to correct both spatial and chromatic distortion (chromatic aberration), and the scene was rendered off-screen at about 1.4 times the panel resolution in each dimension. Because some pixels of each panel cannot be seen through the lenses, Valve drew a "hidden area mesh" into the stencil buffer so that the GPU's early stencil rejection skipped pixels the user cannot see, a 17 percent fill-rate reduction (from 457 to 378 million pixels per second at 1512 x 1680 per eye and 90 Hz). Trimming the distortion mesh itself cut the cost of the warp pass by another 15 percent.[4]
The warp also wastes work in the earlier stages: a planar projection renders many pixels that the distortion step then cuts out. NVIDIA's Lens Matched Shading for its Pascal GPUs, which the company explained to Road to VR in May 2016, uses Simultaneous Multi-Projection to split each eye's view into four quadrants that "better approximate the final distorted view"; NVIDIA said this could give "up to a 50% increase in throughput available for pixel shading".[23] NVIDIA describes it as an improvement on its earlier Multi-res shading technique.[24] In an academic comparison at High Performance Graphics 2016, Robert Toth, Jim Nilsson and Tomas Akenine-Möller of Intel noted that in the new VR displays "pixels no longer appear on regular grids and the displays subtend a wide field-of-view"; they reported that rendering multiple optimized sub-projections could cut the number of rendered pixels to 36 percent "without compromising visual fidelity compared to traditional rendering".[25]
Variable shading rates and foveation
Variable rate shading and related features change how many fragment shader invocations the pipeline runs per pixel. The Vulkan extension VK_KHR_fragment_shading_rate lets "multiple pixels" be shaded "by a single fragment shader invocation", with the rate set per draw, per primitive, or per region of the framebuffer through an image attachment.[26] VK_EXT_fragment_density_map, whose contributors are mostly Qualcomm engineers, lets an application mark areas of the render target where the fragment shader may run fewer times; the specification gives its primary use as reducing work "in areas where lower quality may not be perceived such as the distorted edges of a lens or the periphery of a user's gaze".[6]
Fixed foveated rendering on Meta Quest headsets works at this level. Meta states that FFR "is implemented by controlling the resolution of individual render tiles on the GPU", with tiles near the edges of the eye buffer rendered at lower resolution according to a resolution multiplier map, also called the fragment density map. In Meta's test scene, the low, medium and high settings improved performance by 6.5, 11.5 and 21 percent; Meta says FFR can give a 25 percent gain in pixel-intensive applications but may not help, or may cost performance, in applications with simple shaders.[27] Apple's Metal has variable rasterization rates, set with a rasterization rate map, and on visionOS the drawable provides rate maps that render the parts of the image in a person's peripheral vision at lower resolution; these maps are available only when foveation is enabled.[28][29]
A 2023 survey by Lili Wang, Xuehuai Shi and Yi Liu in Computational Visual Media, covering foveated rendering research from 1990 to 2021, names integration "into existing rendering paradigms" as one of the field's three main problems, alongside perceptual models of the human visual system and methods for rendering regions at different quality.[30]
Tile-based GPUs in standalone headsets
Standalone headsets use mobile GPUs that organize the pipeline around screen tiles. Meta's developer documentation states that "All Meta Quest devices use tile-based rendering". Mobile GPUs must keep power consumption to about 3-6 watts, which Meta says is possible only with 1-5 megabytes of on-GPU memory, too little to hold a whole output texture. The GPU therefore first runs the vertex shaders for every draw call in a render pass and records which tiles each triangle touches (binning); each tile is then rendered to completion and sent to system memory.[31] Meta's GPU profiling guide names the Adreno 650 in the Meta Quest 2 and the Adreno 740v3 in the Meta Quest 3 and Meta Quest 3S, and explains that all draw calls for a frame are executed in two stages. In the binning phase, triangle vertex positions are calculated and assigned to bins; in the render phase, the full vertex shaders run again for each bin to compute the interpolants used by the fragment shader, after a simplified version ran during binning.[32] This tile structure is what Meta's fixed foveated rendering uses to vary resolution across the frame.[27]
Reprojection after the pipeline
Some VR work happens after the application's pipeline has finished a frame. J. M. P. van Waveren described the time warp at the ACM VRST conference in 2016: it corrects for the optical aberration of the headset lenses and transforms the stereoscopic images using the latest head-tracking data, running as close as possible to the display refresh. Run asynchronously to rendering (Asynchronous timewarp), it can raise the perceived frame rate and smooth out inconsistent frame rates, but the paper notes that a fast, predictable implementation is hard on consumer hardware.[33] More advanced reprojection needs extra outputs from the pipeline. OpenXR's XR_KHR_composition_layer_depth extension lets applications submit depth images with their color images so the runtime can "perform more accurate reprojections taking depth into account".[17] Meta's Application SpaceWarp requires the application to render a motion vector pass, with depth recorded in the depth buffer, and to modify its materials and render pipeline; the application then renders at half rate. Meta reported that in initial testing it gave apps "up to 70 percent additional compute".[34]
Research
Steven Molnar, Michael Cox, David Ellsworth and Henry Fuchs reviewed the "standard feed-forward rendering pipeline" in a 1994 paper and classified parallel renderers by where the sort from object coordinates to screen coordinates takes place, which they considered fundamental whenever both geometry processing and rasterization run in parallel.[35]
For VR, researchers have also questioned the frame-based pipeline itself. Sebastian Friston, Anthony Steed, Simon Tilbury and Georgi Gaydadjiev built an FPGA ray-casting renderer with a latency of about 1 ms from tracker to pixel and described it in IEEE Transactions on Visualization and Computer Graphics in 2016. Its frameless design means the lowest-latency region of the display follows the scan beam, whereas in frame-based systems "such as those using typical GPUs" latency increases as scan-out proceeds. Tested on an Oculus Rift DK2 against an equivalent GPU-based setup, their system reproduced the stimuli of an ideal zero-latency VR system more faithfully.[36]
See also
References
- ↑ 1.0 1.1 Tomas Akenine-Möller, Eric Haines, Naty Hoffman, Angelo Pesce, Michał Iwanicki, Sébastien Hillaire (2018-08). "Chapter 2: The Graphics Rendering Pipeline (Real-Time Rendering, Fourth Edition)". Real-Time Rendering, 4th ed. (A K Peters/CRC Press, 2018). O'Reilly Media. doi:10.1201/b22086-2. http://web.archive.org/web/20251224134753/https://www.oreilly.com/library/view/real-time-rendering-fourth/9781351816144/xhtml/ch02.xhtml. Retrieved 2026-10-11.
- ↑ 2.0 2.1 2.2 2.3 2.4 "Pipelines". Vulkan Specification. The Khronos Group. https://docs.vulkan.org/spec/latest/chapters/pipelines.html. Retrieved 2026-10-11.
- ↑ 3.0 3.1 3.2 Erik Lindholm, John Nickolls, Stuart Oberman, John Montrym (2008-03). "NVIDIA Tesla: A Unified Graphics and Computing Architecture". IEEE Micro, vol. 28, no. 2, pp. 39-55. IEEE Computer Society. doi:10.1109/MM.2008.31. https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/Arch/gpu.pdf. Retrieved 2026-10-11.
- ↑ 4.0 4.1 4.2 4.3 Alex Vlachos (2015-03). "Advanced VR Rendering (presentation slides)". Game Developers Conference 2015. Valve. https://media.steampowered.com/apps/valve/2015/Alex_Vlachos_Advanced_VR_Rendering_GDC2015.pdf. Retrieved 2026-10-11.
- ↑ 5.0 5.1 "OVR_multiview (OpenGL Extension #478, OpenGL ES Extension #241)". Khronos OpenGL Registry. The Khronos Group. 2018-10-19. https://registry.khronos.org/OpenGL/extensions/OVR/OVR_multiview.txt. Retrieved 2026-10-11.
- ↑ 6.0 6.1 "VK_EXT_fragment_density_map(3)". Vulkan API Reference Pages. The Khronos Group. https://registry.khronos.org/vulkan/specs/latest/man/html/VK_EXT_fragment_density_map.html. Retrieved 2026-10-11.
- ↑ 7.0 7.1 Mark Segal, Kurt Akeley (1994-07-01). "The OpenGL Graphics System: A Specification (Version 1.0)". Khronos OpenGL Registry. Silicon Graphics, Inc.. https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf. Retrieved 2026-10-11.
- ↑ "Graphics pipeline (Direct3D 11)". Microsoft Learn. Microsoft. 2022-02-23. https://learn.microsoft.com/en-us/windows/win32/direct3d11/overviews-direct3d-11-graphics-pipeline. Retrieved 2026-10-11.
- ↑ 9.0 9.1 9.2 David Blythe (2006-07). "The Direct3D 10 System". ACM Transactions on Graphics, vol. 25, no. 3 (SIGGRAPH 2006), pp. 724-734. ACM. doi:10.1145/1141911.1141947. https://neilrieck.net/misc/pdf/computer-docs/DirectX10.pdf. Retrieved 2026-10-11.
- ↑ Sarah Jobalia (2019-11-08). "Coming to DirectX 12 - Mesh Shaders and Amplification Shaders: Reinventing the Geometry Pipeline". DirectX Developer Blog. Microsoft. https://devblogs.microsoft.com/directx/coming-to-directx-12-mesh-shaders-and-amplification-shaders-reinventing-the-geometry-pipeline/. Retrieved 2026-10-11.
- ↑ Ivan E. Sutherland (1968). "A head-mounted three dimensional display". AFIPS Fall Joint Computer Conference 1968, pp. 757-764. doi:10.1145/1476589.1476686. https://web.stanford.edu/class/ee267/notes/sutherland_hmd.pdf. Retrieved 2026-10-11.
- ↑ James H. Clark (1982-07). "The Geometry Engine: A VLSI Geometry System for Graphics". ACM SIGGRAPH Computer Graphics, vol. 16, no. 3 (SIGGRAPH '82), pp. 127-133. ACM. doi:10.1145/965145.801272. https://archive.org/download/bitsavers_sgiirisgeok_1057823/p127-clark.pdf. Retrieved 2026-10-11.
- ↑ Jon Peddie (2020-09-24). "Famous Graphics Chips: Geometry Engine". IEEE Computer Society Tech News (Chasing Pixels). IEEE Computer Society. https://www.computer.org/publications/tech-news/chasing-pixels/geometry-engine. Retrieved 2026-10-11.
- ↑ Erik Lindholm, Mark J. Kilgard, Henry Moreton (2001-08). "A User-Programmable Vertex Engine". Proceedings of ACM SIGGRAPH 2001, pp. 149-158. NVIDIA Research. doi:10.1145/383259.383274. https://research.nvidia.com/publication/2001-08_user-programmable-vertex-engine. Retrieved 2026-10-11.
- ↑ Jacques van Rhyn (2019-03-18). "Variable Rate Shading: a scalpel in a world of sledgehammers". DirectX Developer Blog. Microsoft. https://devblogs.microsoft.com/directx/variable-rate-shading-a-scalpel-in-a-world-of-sledgehammers/. Retrieved 2026-10-11.
- ↑ "IVRCompositor Overview". OpenVR wiki. Valve. https://github.com/ValveSoftware/openvr/wiki/IVRCompositor_Overview. Retrieved 2026-10-11.
- ↑ 17.0 17.1 17.2 "The OpenXR 1.1.63 Specification (with all registered extensions)". Khronos OpenXR Registry. The Khronos Group. https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html. Retrieved 2026-10-11.
- ↑ "VK_KHR_multiview(3)". Vulkan API Reference Pages. The Khronos Group. https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_multiview.html. Retrieved 2026-10-11.
- ↑ "VRWorks - Single Pass Stereo". NVIDIA Developer. NVIDIA. https://developer.nvidia.com/vrworks/graphics/singlepassstereo. Retrieved 2026-10-11.
- ↑ "Improving rendering performance with vertex amplification". Apple Developer Documentation. Apple. https://developer.apple.com/documentation/metal/improving-rendering-performance-with-vertex-amplification. Retrieved 2026-10-11.
- ↑ "LayerRenderer.Layout.layered". Apple Developer Documentation. Apple. https://developer.apple.com/documentation/compositorservices/layerrenderer/layout/layered. Retrieved 2026-10-11.
- ↑ "Introduction to stereo rendering". Unity Manual (Unity 6.6). Unity Technologies. https://docs.unity3d.com/Manual/SinglePassStereoRendering.html. Retrieved 2026-10-11.
- ↑ Ben Lang (2016-05-17). "NVIDIA Explains Pascal's 'Lens Matched Shading' for More Efficient VR Rendering". Road to VR. https://www.roadtovr.com/nvidia-explains-pascal-simultaneous-multi-projection-lens-matched-shading-for-vr/. Retrieved 2026-10-11.
- ↑ "VRWorks - Lens Matched Shading". NVIDIA Developer. NVIDIA. https://developer.nvidia.com/vrworks/graphics/lensmatchedshading. Retrieved 2026-10-11.
- ↑ Robert Toth, Jim Nilsson, Tomas Akenine-Möller (2016). "Comparison of Projection Methods for Rendering Virtual Reality". High Performance Graphics 2016, pp. 163-171. Eurographics Association. doi:10.2312/hpg.20161202. https://fileadmin.cs.lth.se/graphics/research/papers/2016/VR/. Retrieved 2026-10-11.
- ↑ "VK_KHR_fragment_shading_rate(3)". Vulkan API Reference Pages. The Khronos Group. https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_fragment_shading_rate.html. Retrieved 2026-10-11.
- ↑ 27.0 27.1 "Fixed foveated rendering (FFR)". Meta Horizon OS Developers. Meta. https://developers.meta.com/horizon/documentation/unity/os-fixed-foveated-rendering/. Retrieved 2026-10-11.
- ↑ "rasterizationRateMaps". Apple Developer Documentation (Compositor Services). Apple. https://developer.apple.com/documentation/compositorservices/layerrenderer/drawable/rasterizationratemaps. Retrieved 2026-10-11.
- ↑ "Rendering at different rasterization rates". Apple Developer Documentation. Apple. https://developer.apple.com/documentation/metal/rendering-at-different-rasterization-rates. Retrieved 2026-10-11.
- ↑ Lili Wang, Xuehuai Shi, Yi Liu (2023-06). "Foveated rendering: A state-of-the-art survey". Computational Visual Media, vol. 9, no. 2, pp. 195-228. Springer. doi:10.1007/s41095-022-0306-4. https://doi.org/10.1007/s41095-022-0306-4. Retrieved 2026-10-11.
- ↑ "Mobile GPUs and tiled rendering". Meta Horizon OS Developers. Meta. https://developers.meta.com/horizon/documentation/native/android/gpu-tiled/. Retrieved 2026-10-11.
- ↑ "Use ovrgpuprofiler for GPU Profiling". Meta Horizon OS Developers. Meta. https://developers.meta.com/horizon/documentation/native/android/ts-ovrgpuprofiler/. Retrieved 2026-10-11.
- ↑ J. M. P. van Waveren (2016-11-02). "The asynchronous time warp for virtual reality on consumer hardware". Proceedings of the 22nd ACM Conference on Virtual Reality Software and Technology (VRST '16), pp. 37-46. ACM. doi:10.1145/2993369.2993375. https://doi.org/10.1145/2993369.2993375. Retrieved 2026-10-11.
- ↑ "Application SpaceWarp Developer Guide". Meta Horizon OS Developers. Meta. https://developers.meta.com/horizon/documentation/unity/unity-asw/. Retrieved 2026-10-11.
- ↑ S. Molnar, M. Cox, D. Ellsworth, H. Fuchs (1994-07). "A sorting classification of parallel rendering". IEEE Computer Graphics and Applications, vol. 14, no. 4, pp. 23-32. IEEE. doi:10.1109/38.291528. https://doi.org/10.1109/38.291528. Retrieved 2026-10-11.
- ↑ Sebastian Friston, Anthony Steed, Simon Tilbury, Georgi Gaydadjiev (2016-04). "Construction and Evaluation of an Ultra Low Latency Frameless Renderer for VR". IEEE Transactions on Visualization and Computer Graphics, vol. 22, no. 4, pp. 1377-1386. IEEE. doi:10.1109/TVCG.2016.2518079. https://doi.org/10.1109/TVCG.2016.2518079. Retrieved 2026-10-11.