DirectX 12’s latest feature could make future games less CPU-limited

Microsoft has launched Work Graphs 1.0, and it has the potential to make future games faster

With Work Graphs 1.0, Microsoft is promoting GPU-driven rendering and making it possible for future games to run faster. This is due to more efficient resource utilisation, and freed up CPU resources that can be used for other tasks.

Typically, CPUs play a critical role when managing GPU resources. This can cause issues when CPUs spend too much time allocating resources, or makes an incorrect guess that wastes rendering time. With their Agility 1.613 SDK comes work graphs, which allow GPUs to generate work for itself and require less management from a users CPU.

With GPUs being able to schedule work for itself, fewer tasks need to go back and forth from CPUs to GPUs. This should free up a lot of CPU and memory overhead. It should also allow developers to make more creative use of GPU resources.

Below is what Epic Games’ Graham Wihlidal has to say about Work Graphs.

With the proliferation of GPU-driven rendering techniques – such as Nanite in Unreal Engine 5 – the role of the CPU is trending towards primarily resource management and hazard tracking, with only a fraction of time spent generating GPU commands. Prior to D3D12 Work Graphs, it was difficult to perform fine-grained memory management on the GPU, which meant it was practically impossible to support algorithms with dynamic work expansion. Even simple long chains of sequential compute work could result in a significant synchronization and memory overhead.

GPU-driven rendering was accomplished by the CPU having to guess what temporary allocations were needed by the GPU, often over-allocating to the worst case, and using previous frame readback for refinement. Any workloads with dynamic expansion either meant issuing worst case dispatches from the CPU, having the GPU early out of unnecessary work, or non-portable techniques were used, like persistent threads.

With Work Graphs, complex pipelines that are highly variable in terms of overall “shape” can now run efficiently on the GPU, with the scheduler taking care of synchronization and data flow. This is especially important for producer-consumer pipelines, which are very common in rendering algorithms. The programming model also becomes significantly simpler for developers, as complex resource and barrier management code is moved from the application into the Work Graph runtime.

We have been advocating for something like this for a number of years, and it is very exciting to finally see the release of Work Graphs.

(Image from Nvidia)

Don’t expect to see Work Graphs in games anytime soon

Sadly, Microsoft’s new Agility SDK is not going to make all games run faster. Games need to be developed with Work Graphs in mind to benefit from it. That said, future versions of Unreal Engine (and other engines) should support this feature by default.

It will take time for developers to make use of these new features. It will likely be a long time before we see Work Graphs in a shipping game. Sadly, game development times have increased significantly in recent years, and developers are unlikely to add a complex functionality to games that is late in development.

Today, most of the DirectX 12 Ultimate feature set remains widely unused by game developers. This is despite the fact that DirectX 12 Ultimate is now four years old. Alan Wake 2 is the only game we know of that makes use of Mesh Shaders. We have also heard of no games that make use of Sampler Feedback. As of now, ray tracing is the only DirectX 12 Ultimate feature that is widely used, and it is a feature that predates DirectX 12 Ultimate.

You can join the discussion on Microsoft’s new Work Graphs 1.0 feature on the OC3D Forums.