Front render buffering

Front render buffering allows the GPU to render directly to the front buffer to reduce latency. The front buffer is the image that is currently being scanned out to the display; in a conventional double-buffered pipeline the GPU draws into a separate back buffer instead, and the result is only shown after the buffers are swapped. NVIDIA calls the feature "Front Buffer Rendering"; the same idea is also described as single-buffered rendering, and front buffer access is what makes "racing the beam" techniques possible.

Front render buffering is supported by GameWorks VR by Nvidia. It was one of five GameWorks VR features announced for headset and game developers in 2015, alongside VR SLI, Multi-Res Shading, Context Priority and Direct Mode. On mobile VR, John Carmack obtained front buffer access on Samsung phones for the Samsung Gear VR, and later Khronos and Google added single-buffered rendering paths to EGL, Android and Vulkan.

Reviewed 27 September 2026. Checked every cited claim against Nathan Reed's SIGGRAPH 2015 slides and notes, NVIDIA's November 2015 press release, the EGL and Vulkan specifications, the Imagination Technologies and Android Developers blog posts, the Engadget, Gamasutra, TechCrunch and Road to VR articles, the Friston et al. abstract, Lincoln's dissertation, the van Waveren ATW source and the current VRWorks page. About review dates.

How it works

Most real-time renderers use double buffering: the GPU renders into a back buffer while the display reads the front buffer, and the two are swapped at vertical sync. Imagination Technologies summarizes the cost for VR: "the content rendered right now will be visible to the user one frame later." Double buffering and synchronization between the renderer and the display exist to prevent tearing, which appears when one part of the screen shows a new image while another still shows the old one.

With single buffering the application "render[s] always to the buffer which is on screen", and the synchronization that normally protects against tearing has to be switched off. The Vulkan specification states the same trade-off for its shared presentable image mode: because the presentation engine and the application have concurrent access to a single image, and the presentation engine "may update the current image at any point", the mode "may result in visible tearing". To avoid visible tearing, a front-buffer renderer has to coordinate its writes with the display's scan-out.

Two approaches do this. Nathan Reed of NVIDIA described "rendering during vblank or racing the beam" as the tricks front buffer access makes possible, and noted that it "takes advanced low-level know-how". In strip rendering, the screen is divided into strips and the application changes the part of the buffer that is not currently being scanned out. Racing the beam writes a strip just ahead of the scan line; chasing the beam writes the strip behind it. Imagination Technologies describes racing as better for latency but harder to implement, because the GPU must finish within a very tight time window, and recommends chasing as the easier method. It also states that the number of strips is implementation defined and that two strips are optimal in most cases, which in VR gives one strip per eye.

The reason scan-out timing matters is that latency is not uniform across a frame. Friston, Steed, Tilbury and Gaydadjiev note that latency "changes across the display during scan-out": with frame-based GPU rendering it increases as scan-out proceeds, while in their frameless renderer the lowest-latency region of the display immediately follows the scan beam.

History

Research origins

The idea of producing pixels in step with the display predates consumer VR. In his 2017 dissertation on low-latency displays for augmented reality, Peter Lincoln describes the "just-in-time pixels" method of Mine and Bishop (1995), "also known as 'racing the beam'" after the electron beam of CRT displays, in which each pixel is generated for the moment it is sent to the display. He also describes the frameless rendering scheme of Bishop et al. (1994), proposed to avoid both "the latency incurred by double-buffering, and the image tearing incurred by not double-buffering".

Mobile VR

Front buffer access was one of the requirements John Carmack raised with Samsung while developing the Gear VR. Reporting on his talk at Oculus Connect in September 2014, Gamasutra wrote that Android triple-buffers graphics, "inducing a 48 millisecond delay into the system". In an interview with Engadget the same month, Carmack said, "We need the ability to draw directly to the screen without this triple buffering." He described first hacking a phone to get front buffer access, and said the result "cuts out two frames of latency". According to Carmack, Samsung then "went and wrote a proper interface for it" and gave him an extension that provided the access without his workaround.

When the Oculus Mobile SDK became available to developers in November 2014, "Direct front buffer rendering" was listed among its features together with Asynchronous Timewarp, clock frequency locking and GPU context priorities.

PC VR and GameWorks VR

On Windows PCs, DirectX 11 does not normally expose the front buffer. NVIDIA's Direct Mode, which hides a connected headset from the operating system so that VR applications get exclusive access to it, is what gave NVIDIA a way to offer front buffer rendering. In his SIGGRAPH 2015 talk on GameWorks VR (August 2015), Reed said that "Another benefit of Direct Mode is that we can expose the ability to render directly to the front buffer", and his slide listed the feature as "For low-level wizards". He grouped it with context priority and Direct Mode as the lower-level GameWorks VR features "intended for VR headset developers to use in their software stack", while VR SLI and multi-res shading were aimed at game and engine developers. Road to VR published the same explanation in June 2015.

NVIDIA's November 2015 press release describes Front Buffer Rendering as enabling "the GPU to render directly to the front buffer to reduce latency". The same wording appeared in Road to VR's December 2015 overview of GameWorks VR features and their integration with Unreal Engine. The feature was also available on Quadro graphics cards through DesignWorks VR.

Graphics API standards

The Khronos Group's EGL_KHR_mutable_render_buffer extension lets an application toggle front-buffer rendering for a window surface after the surface has been created. Its contributors include John Carmack and Cass Everitt; it was approved by the EGL Working Group on 28 January 2016 and ratified by the Khronos Board of Promoters on 11 March 2016. The specification expects the toggle to be used rarely, "for example... once when enabling a VR accessory and once when disabling it", and it does not guarantee when rendering results appear on screen. Imagination Technologies said it implemented single buffering in this extension, and noted that the extension needs support from both the GPU driver and the Android operating system.

In May 2016, Google's Dave Burke announced that Android N had a VR mode with performance features for developers "including single buffer rendering and access to an exclusive CPU core for VR apps". He gave the motion-to-photon latency on a Nexus 6P running Developer Preview 3 as under 20 ms.

For Vulkan, the VK_KHR_shared_presentable_image extension allows the application to use a swapchain image while the presentation engine is accessing it, "in order to reduce the latency between rendering and presentation". Its contributors came from Samsung, Google, NVIDIA, AMD, Imagination Technologies and Oculus (Cass Everitt and Johannes van Waveren), and the specification notes that "most VR applications do not need to switch between normal and shared usage". It adds two present modes. In the demand-refresh mode the application must make a presentation request whenever an update is required; in the continuous-refresh mode a single initial request is enough and the presentation engine then updates the image on its regular refresh cycle.

Implementation	Platform	Organization	Date	Notes
Front buffer access for Gear VR	Samsung Android phones	Samsung, John Carmack	2014	Samsung wrote an interface after Carmack's workaround
Direct front buffer rendering	Oculus Mobile SDK	Oculus VR	November 2014	Listed with Asynchronous Timewarp and GPU context priorities
Front Buffer Rendering	GameWorks VR (Windows)	Nvidia	2015	Enabled by Direct Mode; aimed at headset developers
EGL_KHR_mutable_render_buffer	EGL (Android)	Khronos Group	Ratified 11 March 2016	Toggles front-buffer rendering on an existing window surface
Single buffer rendering in VR mode	Android N	Google	Announced 18 May 2016	Part of "VR Mode in Android", with an exclusive CPU core for VR apps
VK_KHR_shared_presentable_image	Vulkan	Khronos Group	Last modified 20 March 2017	Shared presentable image with demand or continuous refresh

Relationship to other latency techniques

Front buffer rendering targets one part of the motion-to-photon pipeline, the wait between finishing a frame and scanning it out. Reed's talk set the context: the Oculus Rift and HTC Vive required 90 frames per second, and research indicated that total motion-to-photons latency should be at most 20 milliseconds for comfort.

It is closely tied to asynchronous time warp. NVIDIA's context priority feature lets a VR compositor run on a high-priority GPU context that preempts other rendering, so that a frame can be re-warped when a game misses its deadline. J.M.P. van Waveren's asynchronous time warp test utility for OpenGL, published in the Khronos Group's GitHub samples repository, lists implementing "an OpenGL extension that allows rendering directly to the front buffer" among its work items, next to context priorities and accurate display refresh timing.

Research systems have taken scan-out synchronized rendering further than GPU front buffer access. Friston et al. built a ray-casting renderer on an FPGA with a latency of about 1 ms from tracker to pixel, tested on an Oculus Rift DK2.

Current status

NVIDIA's current VRWorks developer page lists Direct Mode and Display Stream Compression as its features for headset manufacturers, and describes Direct Mode as using Context Priority, late latch and asynchronous time warp; it does not name front buffer rendering as a separate feature.

See also

• GameWorks VR
• Direct Mode
• Context Priority
• Asynchronous Timewarp
• Motion-to-photon latency
• Low persistence