Fixed foveated rendering
More actions
- See also: Terms and Technical Terms
Fixed foveated rendering (FFR) is a form of Foveated rendering that keeps a region of high image quality at a fixed position in each eye's rendered view, usually near the center, while reducing detail farther from that region. It reduces work in the Graphics Processing Unit (GPU), particularly fragment shading, without requiring eye tracking. The pattern is fixed relative to the view, rather than to an object in the world or the user's current gaze.[1]
FFR is used in Virtual Reality (VR) rendering. Looking toward a display edge can bring its reduced-quality image onto the fovea. Gaze-contingent rendering moves the high-quality region with measured gaze instead.[2] A setting called dynamic fixed foveation can change the amount of FFR according to GPU load while retaining the fixed pattern; the word "dynamic" does not always mean eye tracking.[3]
How it works
The human visual system resolves fine detail most clearly near the point of fixation. The central retina has a high concentration of cone cells, while visual performance farther from fixation differs in spatial resolution and other respects. This uneven distribution motivates foveated image generation.[4] The change is gradual, and the dimensions of anatomical regions do not directly prescribe an FFR quality profile. Peripheral recognition also depends on contrast, the task and surrounding visual clutter.[5]
The rendering pipeline can reduce shading rates while retaining finer visibility sampling.[6] Alternatively, it can use separate views with different resolutions.[7] A fixed profile generally needs a broader high-quality region than a gaze-following profile to accommodate looking around.[4]
Resolution zones
Zone geometry depends on the implementation; concentric rings and a universal two-to-four-zone layout are not requirements. Qualcomm's texture-foveation interface describes focal points and a minimum pixel density.[1]
For coarse shading, the rate describes how many pixels share one shader invocation. Illustrative rates are:[8]
| Rate | Shader invocation covers | Meaning |
|---|---|---|
| 1x1 | One pixel | Full per-pixel shading[8] |
| 1x2 or 2x1 | Two pixels | Reduction in one direction[8] |
| 2x2 | Four pixels | One quarter as many shading invocations for a fully covered block[8] |
| 4x4 | Sixteen pixels | Requires AdditionalShadingRatesSupported in Direct3D 12[8]
|
These shading-density ratios do not measure total GPU time; visibility and other stages still require work.[6]
Technical implementation
Variable rate shading
Variable rate shading (VRS), or coarse pixel shading, separates fragment-shader evaluation from geometric visibility sampling. Several pixels can share one shading result while visibility is resolved at a finer rate. Uniformly shrinking an eye buffer also reduces its rasterized spatial resolution.[6]
An image-based implementation supplies a map of rates for screen regions. Direct3D 12 distinguishes per-draw Tier 1 VRS from Tier 2, which also supports an image attachment and per-primitive inputs. Applications must query the available capabilities, including support for additional coarse rates. A GPU's architecture name alone is not a complete compatibility check.[8] In Vulkan, VK_KHR_fragment_shading_rate provides pipeline, primitive and attachment methods, subject to supported features.[9]
The original coarse pixel shading research demonstrated a fixed-center peripheral variant. Texture level-of-detail compensation helped address discontinuities where quantized shading rates changed.[6]
Multi-resolution rendering
Swafford and colleagues rendered a low-resolution full field of view plus a limited high-resolution view at the fixation point, with upsampling and a blended border. Controlled-fixation results do not establish quality during arbitrary eye movements through a fixed profile.[10]
Multiple regions do not automatically save geometry processing. Separate rendering passes may repeat geometry submission and add compositing cost. NVIDIA's historical Multi-Res Shading implementation used a 3x3 viewport arrangement and hardware geometry broadcast to avoid running the geometry pipeline repeatedly for those viewports. Its purpose was to reduce pixels rendered in regions compressed by the headset's image-distortion pass, with the strongest benefit in pixel-bound applications.[7]
Swafford also reduced terrain tessellation explicitly. Geometry savings were a separate technique, not an automatic consequence of lowering peripheral image resolution.[10]
Lens-matched shading
Lens distortion correction changes the relationship between the image rendered by an application and the pixels finally displayed. A rectangular render can contain peripheral detail that is reduced or discarded by that correction. Lens-matched rendering attempts to avoid producing some of those pixels in the first place.[7]
NVIDIA's Lens Matched Shading, introduced for its Pascal Simultaneous Multi-Projection hardware, renders to a surface shaped more like the lens-corrected output than the earlier multiple-viewport approach. It is an optical and projection-related optimization with a fixed spatial distribution. It should not be treated as a measurement of retinal acuity or as an eye tracker. The historical feature's name also does not mean that all FFR implementations use its hardware or projection method.[11]
Runtime foveation profiles
OpenXR runtimes can expose optional foveation extensions. For the XR_FB_foveation family, an application creates a foveation-capable swapchain, creates a profile and applies it with xrUpdateSwapchainFB. XR_FB_foveation_configuration supplies None, Low, Medium and High levels, a vertical offset in degrees, and a dynamic-level option. The dynamic option adjusts intensity according to available performance headroom, up to the requested maximum. It still describes a fixed foveation pattern.[12]
The graphics path matters. The same extension family distinguishes OpenGL scaled-bin foveation from Vulkan fragment-density-map foveation. XR_FB_foveation_vulkan exposes the associated density-map images. XR_META_foveation_eye_tracked adds a separate eye-tracked profile and availability query. Applications must check runtime support and enable the relevant extensions; OpenXR use alone does not establish that these features are present.[12]
Perceptual considerations and artifacts
Visual acuity distribution
Peripheral vision is not simply a blurred version of central vision. The ability to identify fine patterns, the ability to detect a pattern and the effect of nearby distractors can have different limits. The review by Strasburger and colleagues describes a smooth transition rather than one fixed anatomical boundary, and documents why acuity alone does not predict every peripheral recognition task.[5]
A display-relative quality zone changes retinal eccentricity as the eyes move.[2]
Contrast sensitivity and motion detection
Patney and colleagues found that peripheral filtering could reduce contrast and produce a tunnel-like visual impression. Their gaze-tracked renderer combined filtered shading, contrast preservation and temporal reconstruction.[13]
Tursun and colleagues used local luminance contrast and a low-resolution input to predict spatially varying quality. This gaze-based research extends eccentricity-only models; it does not establish that a fixed display profile always matches peripheral vision.[14]
Potential artifacts
Quality reduction can produce several kinds of visible error. Which ones occur depends on sampling, reconstruction and content.[15]
| Artifact | How it can appear |
|---|---|
| Blur or loss of contrast | Fine texture and text lose detail; filtering can alter the appearance of the peripheral scene.[15] |
| Shimmering or flicker | Undersampled detail changes as the scene or head moves.[15] |
| Shading aliasing | Specular highlights and other high-frequency shading vary incorrectly.[15] |
| Visible rate boundaries | Changes in sampling or texture detail expose the edge of a region.[6] |
| Blockiness | Several pixels share visibly coarse shading results.[6] |
| Ghosting | Temporal reconstruction retains inappropriate information from earlier frames.[15] |
Patney's specialized temporal anti-aliasing improved stability but still had ghosting and flicker limitations under severe undersampling. Ordinary TAA is therefore not a guaranteed remedy for aggressive FFR.[13] Tursun's spatial model excluded temporal VRS aliasing.[14]
Advantages and disadvantages
Advantages
Meta identifies GPU-fill bottlenecks and expensive pixel shaders as suitable cases for FFR. Simple shaders can yield little benefit or a loss because of fixed overhead.[16] Savings can instead provide headroom for larger eye textures.[16]
FFR requires no gaze-following update loop. The Meta SDK exposes fixed-level controls independently of eye tracking.[17] Foveated transmission sends reduced data to the display for reconstruction there. Its bandwidth and power savings are distinct from rendering savings; a shader-work reduction alone is not a battery-life measurement.[4]
Disadvantages and limitations
Small text or important detail near an edge may be degraded when a user looks at it. Meta recommends considering high-contrast interface placement.[16]
Tursun's implementation targeted shading and explicitly excluded geometry-pass cost.[14] Coarse shading does not itself simplify geometry or remove unrelated CPU work. Shader invocation counts and overall frame time are different measurements.[6]
Published fixation tests cannot establish acceptable quality during unrestricted viewing.[10] FFR has no universal workload reduction, latency benefit, battery-life extension or comfort guarantee.
Comparison to dynamic foveated rendering
Eye-tracked dynamic foveated rendering uses measured gaze to position the high-quality region. A fixed profile accommodates a range of possible gaze directions with a broader quality distribution; a gaze-following profile can concentrate quality around the measured fixation, subject to tracking accuracy and update delay.[4]
| Feature | Fixed foveated rendering | Eye-tracked foveated rendering |
|---|---|---|
| High-quality region | Fixed relative to the rendered view[1] | Follows measured gaze[1] |
| Eye tracking | Not required[1] | Required for gaze-contingent placement[1] |
| Changing intensity | Can adapt to workload without moving with the eyes[3] | Can adjust quality as well as gaze position[12] |
| Looking off-center | May expose lower-quality regions[2] | Can place high quality at the new fixation after an update[2] |
| Additional requirements | A supported rendering implementation[1] | Eye-tracking availability and timely gaze updates[4] |
| Performance comparison | Depends on profile, content and bottleneck[16] | Also depends on region size and gaze accuracy[4] |
Gaze-update delay is a specific issue for eye-tracked foveation. Albert's study tested artifact detection using three rendering techniques and different foveation mappings. Its HMD experiment involved nine observers viewing a classroom scene, with deliberately added tracker delay. The study found that sufficiently large delays reduced the acceptable foveation. These conditions do not define a universal latency threshold for FFR or a guarantee of user comfort.[15]
Performance-adaptive FFR should be distinguished from that gaze-following mechanism. In Meta's Unreal interface, the selected level is a ceiling and isDynamic permits GPU-utilization-based level adjustment. The high-quality region remains part of a fixed profile.[3]
Hardware, software support, and applications
Support depends on the device, graphics API, runtime, engine version and rendering path. A platform label is not enough to establish compatibility.
Standalone VR headsets
Meta illustrates FFR maps on Quest hardware, including Quest 3; maps and tile boundaries vary with headset and configuration.[16] In the Meta Unity SDK path, OVRManager.foveatedRenderingLevel selects a level and OVRManager.useDynamicFoveatedRendering enables automatic adjustment. OpenXR treats the legacy HighTop enum like High.[17]
Meta's companion subsampled-layout feature requires Vulkan and Unity OpenXR Plugin 1.9.0 or later. Its purpose includes reducing bandwidth and peripheral pixelation; this feature is distinct from simply selecting an FFR level.[17]
Console and PC VR
PC rendering can use fixed image-based VRS where the engine and GPU support it. Epic's Unreal Engine 5.8 documentation lists Windows DirectX 12 with VRS Tier 2, Windows Vulkan with VK_KHR_fragment_shading_rate, and Oculus Quest. The page describes attachment-based rendering as proof of concept, lists DLSS incompatibility and says eye-tracked foveation is unsupported in that path. These limits describe the documented engine feature, not every vendor plugin or console implementation.[18]
Mobile VR and AR platforms
Mobile applications configure foveation through a supported graphics or runtime path. For example, the Meta Unity SDK exposes explicit level controls.[17] This rendering configuration must be distinguished from an Augmented Reality SDK's tracking functions; using such an SDK does not by itself demonstrate that FFR is active.
Game engines
In Unity, OpenXR Plugin 1.15.1 documents SRP Foveation for Unity 6, OpenXR 1.11.0+ and URP or HDRP. Enable the OpenXR feature and set XRDisplaySubsystem.foveatedRenderingLevel at runtime: zero disables it and one requests maximum strength. Device mappings can be discrete. The separate GazeAllowed flag permits gaze-based operation when available; otherwise the path performs fixed foveation.[2]
Unity's Legacy Meta API restricts intermediate render targets, affecting some post-processing and camera-stacking paths. This restriction does not describe every provider or SRP implementation.[2]
In Unreal Engine, Epic exposes vr.VRS.HMDFixedFoveationLevel and vr.VRS.HMDFixedFoveationDynamic for its image-based fixed-foveation path.[18] The Meta XR plugin separately provides project settings under Plugins, Meta XR, Mobile, and UOculusXRFunctionLibrary::SetFoveatedRenderingLevel(level, isDynamic). The level and dynamic behavior must be configured through the selected implementation.[3]
Graphics APIs
Direct3D 12 VRS controls shader evaluation rates within a render target.[8] Vulkan's VK_KHR_fragment_shading_rate supports pipeline, primitive and attachment rates.[9] The XR_FB_foveation Vulkan path instead requires VK_EXT_fragment_density_map.[12] OpenGL ES texture foveation is another mechanism, including scaled-bin support.[1] Configuration and capability checks belong to the selected path.
Primary uses
Foveated pipelines can separately optimize rendering, image processing and transmission. A reduction in peripheral shader samples is different from a reduction in display-link traffic.[4]
Research developments
Original research provides techniques for improving foveated images, but many studies use measured gaze or enforced fixation. Their results must be separated from the performance of a fixed production profile.
Patney's 2016 prototype reported up to 70% fewer shaded pixel quads in gaze-tracked DK2 traces at 1184x1464 pixels per eye. The authors stated that hardware changes were needed to realize performance gains. This shading-work measure is not a universal FFR speedup.[13]
Swafford's 2016 evaluation separately varied resolution, ambient-occlusion sampling and terrain tessellation. Nine graphics professionals viewed controlled fixations on a 4K desktop display; one resolution block was discarded. Testing covered spatial artifacts, not unrestricted temporal viewing.[10]
Tursun's 2019 comparison with global adaptation involved 14 participants on desktop and HMD displays. Preference for local adaptation was significant on the desktop but not significant overall on the HMD. Temporal artifacts and geometry cost remained outside the model.[14]
The 2019 DeepFovea project explored neural reconstruction of peripheral video from sparse pixel input. Its original publication abstract describes gaze-contingent operation. This is a reconstruction research direction, rather than evidence that ordinary FFR predicts the user's gaze without eye tracking.[19]
Implementation considerations
FFR needs both performance measurement and visual evaluation on the target device. The following checks address different failure modes:
| Consideration | What to evaluate |
|---|---|
| Bottleneck | Compare GPU and CPU costs with the selected profile.[18] |
| Actual runtime activation | Verify the runtime level; Unity configuration alone leaves foveation off.[2] |
| Eye movement and peripheral UI | Inspect peripheral text. Meta's compositor layers preserve UI pixel density because FFR does not affect them.[16] |
| Rate changes | Meta warns that frequent profile changes within a scene can be visible.[16] |
| Sampling and reconstruction | Test moving textures, highlights and thin details for reconstruction artifacts.[15] |
| Post-processing | Check intermediate-target support in the selected provider path.[2] |
See also
References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 Qualcomm (2017-10-06). "QCOM_texture_foveated". Khronos OpenGL ES Registry. https://registry.khronos.org/OpenGL/extensions/QCOM/QCOM_texture_foveated.txt. Retrieved 2026-10-13.
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Unity Technologies. "Foveated rendering in OpenXR". OpenXR Plugin 1.15.1 documentation. https://docs.unity3d.com/Packages/[email protected]/manual/features/foveatedrendering.html. Retrieved 2026-10-13.
- ↑ 3.0 3.1 3.2 3.3 Meta (2026-04-14). "Using Fixed Foveated Rendering". Meta Horizon OS Developers, Unreal documentation. https://developers.meta.com/vr/documentation/unreal/unreal-ffr/. Retrieved 2026-10-13.
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 Bastani et al. (2017). "Foveated Pipeline for AR/VR Head-Mounted Displays". Information Display 33 (6): 14-35. doi:10.1002/j.2637-496X.2017.tb01040.x. Retrieved 2026-10-13.
- ↑ 5.0 5.1 Strasburger, Rentschler and Jüttner (2011). "Peripheral vision and pattern recognition: A review". Journal of Vision 11 (5): 13. doi:10.1167/11.5.13. Retrieved 2026-10-13.
- ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 Vaidyanathan et al. (2014). "Coarse Pixel Shading". High Performance Graphics 2014: 9-18. Retrieved 2026-10-13.
- ↑ 7.0 7.1 7.2 NVIDIA. "VRWorks - Multi-Res Shading". NVIDIA Developer. https://developer.nvidia.com/vrworks/graphics/multiresshading. Retrieved 2026-10-13.
- ↑ 8.0 8.1 8.2 8.3 8.4 8.5 8.6 Microsoft. "Variable-rate shading (VRS)". Microsoft Learn. https://learn.microsoft.com/en-us/windows/win32/direct3d12/vrs. Retrieved 2026-10-13.
- ↑ 9.0 9.1 Khronos Group. "VK_KHR_fragment_shading_rate". Vulkan Documentation Project. https://docs.vulkan.org/refpages/latest/refpages/source/VK_KHR_fragment_shading_rate.html. Retrieved 2026-10-13.
- ↑ 10.0 10.1 10.2 10.3 Swafford et al. (2016). "User, Metric, and Computational Evaluation of Foveated Rendering Methods". ACM Symposium on Applied Perception 2016: 7-14. doi:10.1145/2931002.2931011. Retrieved 2026-10-13.
- ↑ NVIDIA. "VRWorks - Lens Matched Shading". NVIDIA Developer. https://developer.nvidia.com/vrworks/graphics/lensmatchedshading. Retrieved 2026-10-13.
- ↑ 12.0 12.1 12.2 12.3 Khronos Group. "OpenXR 1.1 Specification, foveation extensions". OpenXR Registry. https://registry.khronos.org/OpenXR/specs/1.1/html/xrspec.html#XR_FB_foveation_configuration. Retrieved 2026-10-13.
- ↑ 13.0 13.1 13.2 Patney et al. (2016). "Towards Foveated Rendering for Gaze-Tracked Virtual Reality". ACM Transactions on Graphics 35 (6): 179:1-179:12. Retrieved 2026-10-13.
- ↑ 14.0 14.1 14.2 14.3 Tursun et al. (2019). "Luminance-Contrast-Aware Foveated Rendering". ACM Transactions on Graphics 38 (4): 98:1-98:14. doi:10.1145/3306346.3322985. Retrieved 2026-10-13.
- ↑ 15.0 15.1 15.2 15.3 15.4 15.5 15.6 Albert et al. (2017). "Latency Requirements for Foveated Rendering in Virtual Reality". ACM Transactions on Applied Perception 14 (4): 25:1-25:13. doi:10.1145/3127589. Retrieved 2026-10-13.
- ↑ 16.0 16.1 16.2 16.3 16.4 16.5 16.6 Meta (2026-10-07). "Fixed foveated rendering (FFR)". Meta Horizon OS Developers. https://developers.meta.com/vr/documentation/unity/os-fixed-foveated-rendering/. Retrieved 2026-10-13.
- ↑ 17.0 17.1 17.2 17.3 Meta (2026-10-07). "Using Fixed Foveated Rendering". Meta Horizon OS Developers, Unity documentation. https://developers.meta.com/vr/documentation/unity/unity-fixed-foveated-rendering/. Retrieved 2026-10-13.
- ↑ 18.0 18.1 18.2 Epic Games. "XR Performance Features". Unreal Engine documentation. https://dev.epicgames.com/documentation/en-us/unreal-engine/xr-performance-features-in-unreal-engine. Retrieved 2026-10-13.
- ↑ Kaplanyan et al. (2019-11-18). "DeepFovea: Neural Reconstruction for Foveated Rendering and Video Compression using Learned Statistics of Natural Videos". Facebook AI Research. https://ai.meta.com/research/publications/deepfovea-neural-reconstruction-for-foveated-rendering-and-video-compression-using-learned-statistics-of-natural-videos/. Retrieved 2026-10-13.