Your GPU's scheduling toggle was pointless in 2020, and a growing list of Windows features now need it

Published Aug 29, 2026, 12:01 PM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account Windows has been deciding for over a decade, on a single CPU thread, what your graphics card should do next. However, in May 2020, Microsoft gave users the option to give that work to the GPU itself, enabled through an opt-in toggle that very few flipped. That feature is called Hardware-Accelerated GPU Scheduling, and if you read into it at the time, there was a fairly unanimous verdict: it does nothing, don't bother. At the time, that was mostly correct: across games, people discovered it made no meaningful framerate change, and it never amounted to anything resembling free additional performance. The thing is, Microsoft said that it was just the beginning of the changes, and Windows 11 features, Nvidia's frame generation, and more actually require it. The second stage of it finally rolled out with the 24H2 release. All of this is to say that the reason to go and check whether it's enabled is nothing to do with frames per second. Instead, it's that a growing list of features won't work when it’s off, and Windows won't necessarily tell you why. The old scheduler forced a choice between latency and overhead Buffering was the industry's answer Before WDDM, applications submitted work to a global GPU queue that essentially ran first-come, first-served. Vista's WDDM 1.0 replaced that with an OS GPU scheduler, driven by a high-priority CPU thread that coordinated, prioritized, and scheduled work from different applications. That was generally fine if the GPU was running one full-screen game, but once it had to do desktop compositing, video decode, browser rendering, and compute workloads, that changed significantly. Windows now had to make decisions about what mattered most in any given moment, and the old design could no longer keep up. Microsoft described the problem as being "a fundamental tension between latency reduction and submission/scheduling overhead." In other words, applications had two options, but both of them were less than ideal. The first was to submit small batches often, meaning that the GPU will work sooner but every submission goes through the kernel, increasing CPU overhead. The alternative was to submit large buffered batches instead, reducing the overhead, except now everything at the back of the queue has to wait. Applications generally hid that cost through buffering, because CPU overhead was easy to measure and optimize for, while the latency cost depended heavily on the workload and how sensitive the user was to it. When you describe "input lag," one of the causes of that could have been that buffering choice and being placed at the back of the queue, and it was a deliberate trade-off. Hardware-accelerated GPU scheduling exists to make that trade unnecessary. HAGS moved the scheduling, not the rendering The name has a lot to answer for When you turn HAGS on, the scheduler which was ordinarily locked to your CPU instead moves to a dedicated scheduling processor on the GPU. The card decides which of its own hardware queues to service, while Windows holds on to parts that need to know things a GPU can't, like which application deserves priority over which other application. With less CPU overhead, there's less reason to buffer. That was literally all HAGS did, and the name is arguably the biggest cause of all of the confusion. Nothing relating to rendering moved, as rendering always took place on the GPU. "Hardware-accelerated GPU scheduling" seemed to be interpreted as "make the GPU go faster," which is why years of tweak and optimization guides have treated it as a way to gain more performance. Steve Pronovost, who led the graphics kernel work at Microsoft, wrote at the time that "changing the scheduler is akin to rebuilding the foundation of a house while still living in it," and that Microsoft shipped it "as a user opt-in, but off by default option" to avoid disrupting a billion machines. The expectation was that "the transition should be transparent, and users should not notice any significant changes," which isn't something you'd normally say about a feature meant to speed things up. That's why independent testers at the time saw basically zero performance improvement, and some games actually performed worse with it enabled. It appeared to be groundwork for something unspecified by Microsoft, which turned out to be exactly right. The hardware flip queue arrived with Windows 11, and it can't run without HAGS Where 2020 criticisms stopped being relevant Windows 11 21H2 brought WDDM 3.0, and with it, the basic hardware flip queue. Microsoft's documentation is rather blunt about its requirements: "Windows currently requires GPU hardware scheduling to be enabled in order for basic hardware flip queue to be enabled on officially released drivers." Microsoft's groundwork took just over a year to start justifying its existence. The first benefit was power consumption. Before the flip queue, the display controller would interrupt the OS on every VSync to report a completed flip, the OS had to submit the next one, and the application had to wake up as well to check on it. By queueing several frames in advance, the CPU can instead stay asleep for a couple of VSync intervals while the display controller works through the queue. There was still one important round trip left, though. Once the GPU finished rendering a frame into the swap chain back buffer, getting that completed frame onto the display could still involve the CPU. For heavy GPU workloads finishing close to VSync, Microsoft says that round trip could make a frame miss its intended presentation time and cause a visible glitch. Fixing that required the advanced hardware flip queue, and Microsoft's requirements for that are even more interesting: basic hardware flip queue and GPU hardware scheduling stage 2. The flip queue isn't designed to make your GPU render more frames per second. Instead, it targets presentation latency, missed presentation deadlines, and power consumption. In other words, HAGS can be simultaneously worthless in a 2020 benchmark and actually a big deal on a 2026 machine. That's also why arguments about its effectiveness are so commonplace; one person tests it, sees no average FPS increase, and concludes others are experiencing a placebo. Meanwhile, someone else sees that their frametimes improved, and wonders how it could be called a placebo. In that scenario, neither tester would be wrong, and they're just measuring different things. The second stage arrived in 24H2 Fences and a kernel that moves out of the way Microsoft's driver documentation refers to native GPU fences as a part of "GPU hardware scheduling stage 2," supported from Windows 11 24H2 with WDDM 3.2. Microsoft doesn't really define what that is anywhere, aside from its 2020 announcement saying that it was "the first phase." Before native fences, a GPU wait wasn't really a GPU wait. Instead, the OS would hold GPU work that depends on the waited value on the CPU, releasing the work to the GPU when the value was signaled. This meant that cross-engine dependencies, a render waiting on compute, or a compositing frame waiting on a video decode, all had to go through the processor. Native fences make it a true GPU-to-GPU wait, handled on the GPU rather than by parking the dependent work on the CPU. This is also what enables the advanced hardware flip queue described earlier: display controllers that support it can flip when rendering completes without needing the CPU round trip. WDDM 3.2 also introduced the infrastructure for user-mode work submission, which is designed to remove the kernel from the normal submit path entirely. The user-mode driver writes a command buffer into a ring buffer and contacts a register sitting in the PCIe BAR, and the GPU picks it up from there. Microsoft stated that this would benefit virtual machines and containers specifically, as a driver inside a guest no longer needed to contact the host every time it wanted to submit something. Nvidia is also a big fan of hardware scheduling when it comes to CUDA, praising the change for allowing its driver to adopt the same strategy used in its native Linux driver, making work submissions instantaneous and avoiding the need for buffering. From what we can gather, the first stage is what substantially decreased the scheduling overhead, and the second stage, WDDM 3.2, is what set the stage for user-mode work submission. On that, though, Microsoft's documentation still describes the feature as under development rather than generally enabled. Still, the end goal is small, frequent, near-instant submissions without the buffering penalty that the old WDDM path encouraged. Nvidia's frame generation doesn't work without it, but Intel's does Same technique, different requirement DLSS Frame Generation won't work on either an RTX 40 or an RTX 50 series card if you switch HAGS off. The same goes for Smooth Motion, which was added in the RTX 50 series. Intel's own support documentation, meanwhile, says that HAGS is supported on Arc B-series cards on Windows 11 22H2 and newer, and that "currently, this is not supported on Intel Arc A-Series Graphics cards." Intel, however, supports XeSS 3 Multi-Frame Generation on its A-series of cards anyway. What this means is that frame generation as a technique clearly doesn't need hardware scheduling: Nvidia's implementation does. Support across Nvidia, AMD, and Intel is... weird, to say the least. While Nvidia supports it on all Pascal cards and up since its launch, AMD released a beta for the RX 5600 and 5700 in Adrenalin 20.5.1 in 2020 before going quiet for three years. Eventually, AMD did release actual support for it with Adrenalin 23.12.1 in December of 2023. Finally, Intel's discrete Alchemist cards never got it at all, and it seems like Intel just... doesn't care. But what makes it even weirder is that Intel does care, because its integrated graphics have had it for years. Windows doesn't really make the decision about whether it's on or not Your driver goes first What decides the natural state of the toggle is a negotiation, rather than a universal default, and it starts with your GPU drivers. When the device turns on, the kernel-mode driver declares how mature its hardware scheduling implementation is on the adapter, picking one of four states, and Windows decides what to do with that declaration. ALWAYS_OFF means the driver never asks about the feature at all, which is what leaves the toggle missing or greyed out. Meanwhile, EXPERIMENTAL means retail Windows won't enable it without a registry override, STABLE leaves the decision to the OS, and ALWAYS_ON means, in Microsoft's own words, that "the driver doesn’t operate without this feature enabled." That last one could explain why some people see the feature switched on by itself after the user switched it off. If your hardware's driver declares ALWAYS_ON, that's the expected behavior. Looking into it, though, I haven't actually seen a single consumer GPU that declares it. I looked specifically for OBS logs, because they conveniently contain that flag at the beginning, and across approximately 180 different readings, I never saw an "Always on" state. Nvidia’s Blackwell cards declare STABLE, same as Ada and Ampere before them. On Windows 11, the registry value that represents this is HwSchMode under HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers, where 2 means on and 1 means off. Microsoft's own documentation misses out on this entirely, though it does have "DXGK_FEATURE_HWSCH" and "HWSCH" rather than "HwSchMode." In fact, all I found while looking for it was an array of "optimizer" scripts, many of which disagreed with each other. Some set it to a value of 2, others set it to a value of 1, but in both claims, it's treated as an "optimization." Looking at my own machines, a clean Windows 11 install in a Proxmox VM has no HwSchMode value at all, even though Windows does set the surrounding keys like DxgKrnlVersion. My main desktop with an RTX 5090, though, has it set to 2. From what I can tell, it seems that not everyone will have it enabled out of the box. Microsoft says they left it as an opt-in setting in order to avoid disruption, but also added that "users can opt-in through the UI and for new systems, OEM are encouraged to configure and validate their system with hardware accelerated GPU scheduling turned on from the factory." This means that Microsoft encourages OEMs building your PC to enable it before it gets to you, which also explains why prebuilts and some newer machines will often arrive with it switched on. In turn, anything upgraded in place from an older Windows could end up with it switched off. The software that cares most about frame delivery treats it as a risk OBS still won't ask for realtime priority The reason I went looking for OBS logs was simple: it has a rather dicey history with HAGS. In fact, if you have the setting enabled, it will flag a warning in the log file, so that users reporting issues can show if it's on or off. The reason behind the dicey history is that, with HAGS off, it asks Windows for realtime GPU scheduling priority, and with HAGS on, it'll settle for high. I found the original GitHub PR for that, and it was merged in May 2023, stating only that "testing showed that HAGS related crashes do not occur when using a lower priority." There's a follow-up draft PR that exists to lift it as Nvidia's driver is now fixed, but it hasn't been merged and one commenter disagrees with the premise that it's fixed. To be fair, it's not just OBS, either. An OpenXR runtime from 2024 and a separate OpenXR API layer, both from the same developer, check the same registry value in order to log a warning when it's switched on, which lines up with the reputation HAGS has among VR users for causing issues and visual hitching. None of that makes the feature broken, but it does mean a good few developers have been trying to push users away from it for a while now. The thing is, nobody has actually rigorously re-tested any of this since 2020. Most numbers you'll find are six years old and several driver architectures old, and practically every performance number you'll find today ultimately has a lineage that almost certainly goes back several years. The primary metrics that actually matter are frame time distribution and present-to-display latency. If you bought a pre-built PC, chances are that it's already switched on. If you built it yourself, or you've been on the same install through upgrades from Windows 10, it could still be switched off unless you or your drivers enabled it. Keep in mind, though, that if you do enable it, it's not for additional frames. Instead, it's for features like frame generation, the Windows 11 flip queue, and other features Microsoft builds in the future that will assume it's already there. When it launched in 2020, there were reasons to turn it off, but the reasons for turning it off back then don't justify it six years on.