I know this is an MS tech. but it only works with GPU's. My 9700k @ 5180Mhz. is almost never pegged at 100% usage on all cores by any game, but my 4090 is regularly hammered at nearly 100% usage so why would I want to put more load on the GPU?
Here's a brief write-up on it:
The Windows Display Driver Model (WDDM) GPU scheduler is responsible for coordinating and managing multiple different applications submitting work to the GPU.
This relies on “a high-priority thread running on the CPU that coordinates, prioritizes, and schedules the work submitted by various applications.”
The GPU may be responsible for rendering, but the CPU bears the load of preparing and submitting commands to the GPU. Doing this one frame at a time is inefficient,
so a technique called frame buffering has become common, where the CPU submits commands in batches. This increases overall performance,
which could manifest as an increased framerate, but it also increases input latency. When a user hits a button,
nothing will happen until the GPU gets to the next batch of submitted frames. The larger the batch, the longer the potential wait.
The Microsoft blog post describes frame buffering as practically universal, but some games allow adjusting the size of the buffer or disabling it entirely.
Hardware-accelerated GPU scheduling offloads the work from that high-priority CPU thread and instead gives it to “a dedicated GPU-based scheduling processor.”
The fact that cards as far back as Turing have the hardware to support this feature implies that it’s been in the works for some time now.
Microsoft describes the handover as “akin to rebuilding the foundation of a house while still living in it,” in the sense that this is a huge change that
will ideally be invisible to the end user. The most explicit description offered in the post is this: “Windows continues to control prioritization and
decide which applications have priority among contexts. We offload high frequency tasks to the GPU scheduling processor, handling quanta management and
context switching of various GPU engines.” Nowhere in the post does Microsoft directly claim that applications will run faster; instead,
they go out of their way to say that users shouldn’t notice any change.
That hasn’t stopped anyone from looking for magical performance improvements, though. NVIDIA and AMD have encouraged this with vague-but-positive wording.
From NVIDIA: “This new feature can potentially improve performance and reduce latency by allowing the video card to directly manage its own memory.”
From AMD: “By moving scheduling responsibilities from software into hardware, this feature has the potential to improve GPU responsiveness and to allow
additional innovation in GPU workload management in the future.” Both of these descriptions allude to latency, as does the Microsoft post.
This opens up two areas of improvement for testing, summarized by description in the graphics menu, which reads “reduce latency and improve performance.”
The first is input latency, which we can and have tested for during our coverage of Google Stadia, but we don’t think this is as big a deal as some people
expect it to be. Microsoft’s blog post describes hardware-accelerated GPU scheduling as eliminating the need for frame buffering, which is a known source of input latency.
Based on that description, hardware-accelerated GPU scheduling shouldn’t reduce input latency any more than simply disabling frame buffering,
which is already a built-in option in many games, and is further often an option in the GPU driver control panels. The second area of potential improvement is in the
framerate of CPU-bound games, since some amount of work is offloaded from the CPU. The logical assumption is that this effect would be most noticeable on low-end CPUs
that hit 100% load in games, likely more than would be the case in GPU-bound scenarios and with GPU VRAM constraints.
So is it worth enabling it? Or is it a hit and miss proposition like SAM/resizable BAR?
Here's a brief write-up on it:
The Windows Display Driver Model (WDDM) GPU scheduler is responsible for coordinating and managing multiple different applications submitting work to the GPU.
This relies on “a high-priority thread running on the CPU that coordinates, prioritizes, and schedules the work submitted by various applications.”
The GPU may be responsible for rendering, but the CPU bears the load of preparing and submitting commands to the GPU. Doing this one frame at a time is inefficient,
so a technique called frame buffering has become common, where the CPU submits commands in batches. This increases overall performance,
which could manifest as an increased framerate, but it also increases input latency. When a user hits a button,
nothing will happen until the GPU gets to the next batch of submitted frames. The larger the batch, the longer the potential wait.
The Microsoft blog post describes frame buffering as practically universal, but some games allow adjusting the size of the buffer or disabling it entirely.
Hardware-accelerated GPU scheduling offloads the work from that high-priority CPU thread and instead gives it to “a dedicated GPU-based scheduling processor.”
The fact that cards as far back as Turing have the hardware to support this feature implies that it’s been in the works for some time now.
Microsoft describes the handover as “akin to rebuilding the foundation of a house while still living in it,” in the sense that this is a huge change that
will ideally be invisible to the end user. The most explicit description offered in the post is this: “Windows continues to control prioritization and
decide which applications have priority among contexts. We offload high frequency tasks to the GPU scheduling processor, handling quanta management and
context switching of various GPU engines.” Nowhere in the post does Microsoft directly claim that applications will run faster; instead,
they go out of their way to say that users shouldn’t notice any change.
That hasn’t stopped anyone from looking for magical performance improvements, though. NVIDIA and AMD have encouraged this with vague-but-positive wording.
From NVIDIA: “This new feature can potentially improve performance and reduce latency by allowing the video card to directly manage its own memory.”
From AMD: “By moving scheduling responsibilities from software into hardware, this feature has the potential to improve GPU responsiveness and to allow
additional innovation in GPU workload management in the future.” Both of these descriptions allude to latency, as does the Microsoft post.
This opens up two areas of improvement for testing, summarized by description in the graphics menu, which reads “reduce latency and improve performance.”
The first is input latency, which we can and have tested for during our coverage of Google Stadia, but we don’t think this is as big a deal as some people
expect it to be. Microsoft’s blog post describes hardware-accelerated GPU scheduling as eliminating the need for frame buffering, which is a known source of input latency.
Based on that description, hardware-accelerated GPU scheduling shouldn’t reduce input latency any more than simply disabling frame buffering,
which is already a built-in option in many games, and is further often an option in the GPU driver control panels. The second area of potential improvement is in the
framerate of CPU-bound games, since some amount of work is offloaded from the CPU. The logical assumption is that this effect would be most noticeable on low-end CPUs
that hit 100% load in games, likely more than would be the case in GPU-bound scenarios and with GPU VRAM constraints.
So is it worth enabling it? Or is it a hit and miss proposition like SAM/resizable BAR?
