For over a decade, Windows has been at the helm of directing graphics card operations through a single CPU thread. However, in May 2020, Microsoft introduced an option for users to transfer this task to the GPU itself via a feature known as Hardware-Accelerated GPU Scheduling (HAGS). Initially met with skepticism, the consensus was that this feature offered little to no tangible benefits in terms of framerate improvements. Yet, Microsoft hinted that this was merely the beginning, and subsequent updates would necessitate its activation to leverage new features in Windows 11 and Nvidia’s frame generation technology.
The old scheduler forced a choice between latency and overhead
Prior to the advent of Windows Display Driver Model (WDDM), applications submitted their tasks to a global GPU queue, which operated on a first-come, first-served basis. The introduction of WDDM 1.0 in Vista replaced this system with an OS GPU scheduler that prioritized and scheduled tasks based on urgency. While this was effective for single applications, the complexity increased when multiple tasks, such as desktop compositing and video decoding, were involved. Microsoft identified a fundamental tension between latency reduction and submission overhead, leading to a trade-off where applications either submitted small batches frequently—resulting in higher CPU overhead—or larger batches that increased latency for tasks waiting in line. HAGS was designed to eliminate this trade-off.
HAGS moved the scheduling, not the rendering
Activating HAGS shifts the scheduling responsibility from the CPU to a dedicated scheduling processor on the GPU. This allows the GPU to manage its hardware queues autonomously while Windows retains control over application priorities. With reduced CPU overhead, the need for buffering diminishes. However, the name “Hardware-Accelerated GPU Scheduling” has led to misconceptions, with many interpreting it as a means to enhance GPU speed. In reality, the change primarily affects scheduling rather than rendering performance. Steve Pronovost, who led the graphics kernel work at Microsoft, noted that the transition was designed to be seamless, which explains why early tests showed negligible performance improvements.
The hardware flip queue arrived with Windows 11, and it can’t run without HAGS
The introduction of WDDM 3.0 with Windows 11 21H2 brought the basic hardware flip queue, which requires HAGS to function. This advancement significantly reduces power consumption by allowing the CPU to remain idle during VSync intervals while the display controller processes queued frames. However, the advanced hardware flip queue, which addresses presentation latency and missed deadlines, necessitates both the basic hardware flip queue and HAGS. Thus, while HAGS may not have shown immediate benefits in 2020 benchmarks, its importance has grown with newer technologies.
The second stage arrived in 24H2
Microsoft’s driver documentation indicates that native GPU fences are part of “GPU hardware scheduling stage 2,” which became available with Windows 11 24H2 and WDDM 3.2. Native fences allow the GPU to manage dependencies without CPU intervention, facilitating true GPU-to-GPU waits. This change is crucial for enabling the advanced hardware flip queue and aims to streamline work submissions, particularly benefiting virtual machines and containers. Although still under development, the goal is to achieve rapid, small submissions without the penalties associated with older WDDM paths.
Nvidia’s frame generation doesn’t work without it, but Intel’s does
Nvidia’s DLSS Frame Generation and Smooth Motion features require HAGS to be enabled on RTX 40 and 50 series cards. In contrast, Intel’s Arc B-series cards support frame generation without the need for HAGS, showcasing the varying requirements across different manufacturers. While Nvidia has consistently supported HAGS since its inception, AMD’s support has been sporadic, and Intel’s approach has been inconsistent, particularly with its discrete graphics cards.
Windows doesn’t really make the decision about whether it’s on or not
The state of HAGS is determined by a negotiation process initiated by GPU drivers, which declare the maturity of their hardware scheduling implementation. Depending on the declared state—ranging from ALWAYSOFF to ALWAYSON—Windows will either enable or disable the feature. This nuanced approach explains why some users find HAGS enabled by default on pre-built systems while others may need to activate it manually.
The software that cares most about frame delivery treats it as a risk
Applications like OBS have exhibited a cautious relationship with HAGS, often flagging warnings when the feature is enabled due to historical issues with crashes. Despite the mixed reputation of HAGS, rigorous retesting has been sparse since its initial launch, leaving many performance metrics rooted in outdated data. As the landscape evolves, the focus shifts from framerate increases to frame time distribution and presentation latency. For users with pre-built systems, HAGS is likely already enabled, while those with custom builds may need to activate it to access future features that rely on this capability.
