• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Work Graphs coming to a DirectX update near us soon!

L

Lakados

[H]F Junkie
2FA
Joined
Feb 3, 2014
Messages
13,906
https://overclock3d.net/news/gpu-di...mance-gains-using-work-graphs-with-radeon-gpu
https://developer.nvidia.com/blog/advancing-gpu-driven-rendering-with-work-graphs-in-direct3d-12/
https://developer.nvidia.com/blog/work-graphs-in-direct3d-12-a-case-study-of-deferred-shading/
https://github.com/NVIDIAGameWorks/donut_examples/tree/main/examples/work_graphs
https://overclock3d.net/news/softwa...ure-could-make-future-games-less-cpu-limited/

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.

DX12 with the latest Agility update supports them but it will be a good while before games start using them as they have to be built with this rendering method in mind.
 
That's great, but games are mostly GPU-limited these days. Maybe this will reduce sudden frame rate drops?

I expect this to have about as much impact as DX12 did (make slow systems less slow, no impact on mid-fast systems), or that DirectStorage has.
 
jfreund said:
That's great, but games are mostly GPU-limited these days. Maybe this will reduce sudden frame rate drops?

I expect this to have about as much impact as DX12 did (make slow systems less slow, no impact on mid-fast systems), or that DirectStorage has.
Click to expand...
Well a 5800x paired with a 7900xtx got a 39% performance increase in the AMD demo and the Nvidia demo’s out there show significantly better frame times.
 
Last edited:
jfreund said:
That's great, but games are mostly GPU-limited these days. Maybe this will reduce sudden frame rate drops?

I expect this to have about as much impact as DX12 did (make slow systems less slow, no impact on mid-fast systems), or that DirectStorage has.
Click to expand...

This is a good thing, we (usually) want the GPU doing as much work as it possibly can.

It's way easier to optimize for being GPU bound than it is CPU bound - and it's straight up easier to replace the actual hardware.

Half the time you're CPU bound you're practically screwed. Reducing the graphics is going to have little to no effect. You can run at a lower resolution, turn off post processing, etc. etc. and you're still stuck. Versus if you're GPU bound as shit more often than not you dial upscaling a notch and oh you have an immediate performance gain.
 
jfreund said:
That's great, but games are mostly GPU-limited these days. Maybe this will reduce sudden frame rate drops?
Click to expand...
In the dragon game, cpu seem to have quite the effect, without needing a 4090 to show.
https://www.pcgamer.com/games/rpg/dragons-dogma-2-performance-analysis/#section-1440p-performance

1440p with a 7800xt you go from 55 avg fps/38, 1%low to 73/55 with a 7900x, lot of the newest games on a lot of cpu could be leaving 50% of what the gpu could do.

4070ti go from 57/25 to 89/69 from a 9700k to a 14700KF, nearly tripling your lows. In the city where a lot of people-stuff happen it is even more dramatic.

And some stuff that should have made the situation even more GPU bound like Raytracing seem to be asking a lot of the CPU
 
socK said:
This is a good thing, we (usually) want the GPU doing as much work as it possibly can.

It's way easier to optimize for being GPU bound than it is CPU bound - and it's straight up easier to replace the actual hardware.

Half the time you're CPU bound you're practically screwed. Reducing the graphics is going to have little to no effect. You can run at a lower resolution, turn off post processing, etc. etc. and you're still stuck. Versus if you're GPU bound as shit more often than not you dial upscaling a notch and oh you have an immediate performance gain.
Click to expand...
Also, the CPU doesn't necessarily know what the GPU is asking for or what it is trying to do, it's guessing 99% of the time and it's rarely right.

You want the GPU to be as busy as possible and it will always keep itself busy because of how the pipelines work. Still, often it is busy with filler literal dead noise just so it can keep things passed correctly because the CPU provided too little information. Or sometimes the CPU sends too much and it forces the GPU to stop stand up ditch something they are halfway through make a new request for less then start again.
One scenario is leaving performance on the table, and the other is how you get frame hiccups.
In either case, the GPU is asking the CPU to send it resources and allocate work, this works to further remove the CPU from the equation and lets it handle its own tasks.

This is good, it further leads to a separation of work and decouples the respective performance impacts. In theory, it also leads to an easier programming methodology for game engines as they self-optimize their workflows and it becomes less of a developer-side process and places it back in the hands of the GPU driver teams. This could ultimately simplify their jobs as well because it should lessen the amount of per-game optimizations they need to do.
It's a win-win and I completely understand why developers have been asking for this to be a thing for the past few years.
 
VKD3D-Proton, the Vulkan-to-DirectX 12 translation layer used in Valve’s Proton, has reached version 3.0.

developers also noted that this version also brings experimental support for D3D12 Work Graphs. They note that there are no games that use this technology yet, but based on their testing of it, it already runs faster than native implementation after converting it to normal compute shaders.

Source: VKD3D-Proton

https://videocardz.com/newz/vkd3d-p...n-with-an-experimental-support-for-older-gpus
 
Marees said:
VKD3D-Proton, the Vulkan-to-DirectX 12 translation layer used in Valve’s Proton, has reached version 3.0.

developers also noted that this version also brings experimental support for D3D12 Work Graphs. They note that there are no games that use this technology yet, but based on their testing of it, it already runs faster than native implementation after converting it to normal compute shaders.

Source: VKD3D-Proton

https://videocardz.com/newz/vkd3d-p...n-with-an-experimental-support-for-older-gpus
Click to expand...
Mazzspeed said:
Implemented experimental support for D3D12 work graphs. No real-world content ships this yet.
This implementation is far from complete,
but it works on "any" GPU since we emulate the feature with normal compute shaders.
Funnily enough, the performance of this emulation can massively outperform native driver implementations of the feature
in many scenarios we've tested (at the cost of some extra VRAM usage).
See docs/ for more details on implementation and some performance numbers.
Click to expand...
apparently work graphs (support started RDNA 3) is a major feature of RDNA 5

  1. PS6 will get work graphs support (first time for a Playstation)
  2. xbox/directX has had this for a long time
  3. vulkan also added support
  4. next gen game engines need to add this feature
  5. PS6 only games will be very heavy on work graphs
  6. on xbox side cross gen games also can have work graphs but they will be much faster on xbox next / rdna 5


View: https://youtube.com/watch?v=zlWwCrFeH7k
 

Researchers Unveils Real-Time GPU-Only Pipeline for Fully Procedural Trees​

by AleksandarK Jun 23rd, 2025 18:24 Discuss (34 Comments)
A research team from Coburg University of Applied Sciences and Arts in Germany, alongside AMD Germany, introduced a game-changing approach to procedural tree creation that runs entirely on the GPU, delivering both speed and flexibility, unlike anything we've seen before.

Showcased at High-Performance Graphics 2025 in Copenhagen, the new pipeline utilizes DirectX 12 work graphs and mesh nodes to construct detailed tree models on the fly, without any CPU muscle.

Artists and developers can tweak more than 150 parameters, everything from seasonal leaf color shifts and branch pruning styles to complex animations and automatic level-of-detail adjustments, all in real-time. When tested on an AMD Radeon RX 7900 XTX, the system generated and pushed unique tree geometries into the geometry buffer in just over three milliseconds. It then automatically tunes detail levels to maintain a target frame rate, effortlessly demonstrating stable 120 FPS under heavy workloads.


traditional buffer-heavy approach might need tens of GB, but researcher's demo holds onto just 51 KB of persistent state per frame. A scratch buffer of up to 1.5 GB is allocated for work-graph execution, though actual usage varies by GPU driver and can be released or reused afterward.

Static assets, such as meshes and textures, remain unaffected, leaving future opportunities for neural compression or procedural texturing to further enhance memory savings.



Widespread adoption will take time since current support is limited to AMD's RDNA 3+ and NVIDIA's 30-series and newer GPUs. Full game-engine integration and console support are still on the horizon. Looking forward, the researchers are exploring how to extend this flexible, GPU-driven pipeline into ray tracing, possibly by building on-GPU bounding volume hierarchies with the same work-graph framework.


AMD researchers reduce graphics card VRAM capacity of 3D-rendered trees from 38GB to just 52 KB with work graphs and mesh nodes — shifting CPU work to the GPU yields tremendous results​


Trees aren't the only objects that can be rendered with this paradigm. We can expect other objects, and possibly even textures, to be rendered this way in the future. Nvidia is already working on neural texture compression to reduce texture demands on video memory, but work graphs and mesh nodes provide another method of achieving the same goal (and will not be limited to Nvidia GPUs).

https://www.tomshardware.com/pc-com...cpu-work-to-the-gpu-yields-tremendous-results
 

Microsoft disables Work Graphs in Shader Model 6.10 after limited game adoption​

Today, 07:45 GMT • WhyCry



Source: VideoCardz.com
https://videocardz.com/newz/microso...shader-model-6-10-after-limited-game-adoption


Microsoft drops DirectX Work Graphs from Shader Model 6.10, turns to Work Lists instead​

Microsoft is backing away from DirectX 12 Work Graphs for the next Shader Model. Work Graphs will remain supported with Shader Model 6.8 and 6.9, but Microsoft says the feature will not be supported with Shader Model 6.10. The DirectX team has already opened a task to update DXC so Work Graph shaders cannot target SM 6.10.

Work Graphs arrived with Shader Model 6.8 in March 2024 after a preview in 2023. The feature was designed to give GPUs more control over generating and scheduling their own workloads. Instead of repeatedly returning to the CPU to decide which GPU task should run next, shaders could generate work for other shader nodes. AMD, NVIDIA, Intel and Qualcomm all helped Microsoft design the feature, although launch hardware support focused on AMD Radeon RX 7000 and NVIDIA GeForce RTX 30/40 series GPUs.

Microsoft says Work Graph adoption did not happen​

Microsoft now says Work Graphs have not been adopted by games for several reasons. According to the DirectX team, current drivers and hardware are still not fast enough or memory efficient enough for wider use, while the limited installed base makes adoption more difficult. GPU vendors reportedly still have driver and hardware improvements planned, but Microsoft does not want to carry the engineering cost of making Work Graphs work alongside newer Shader Model features such as Linear Algebra.

Message shared on DirectX Discord
The feature is not being deleted from DirectX. Microsoft plans to keep supporting Work Graphs through SM 6.8 and SM 6.9. The team says it could reconsider active development if game developers show stronger interest or if future GPUs make Work Graphs considerably easier to implement. For SM 6.10 and later, however, Work Graphs are currently being disabled rather than extended.

Work Lists may handle part of the same problem​

Microsoft is instead working on a new Direct3D 12 feature called Work Lists. The specification describes it as an extension of the existing ExecuteIndirect model. Work Lists allow the GPU to select a different pipeline state for each draw, compute dispatch or ray tracing dispatch from a GPU-resident program table. Hundreds of different pipelines could therefore be dispatched from one CPU API call without issuing empty ExecuteIndirect calls for every possible pipeline.

Work Lists can also keep dispatch inputs entirely in GPU memory. The planned Tier 2 implementation adds GPU-driven continuation chains, allowing one workload to generate the inputs for another and continue through compute, graphics or ray tracing stages without returning to the CPU. This overlaps with some of the GPU-autonomy goals behind Work Graphs, but Work Lists are not a direct replacement for the Work Graph node programming model.
Click to expand...
 
With DXIL 1.10 we're removing support for Work Graphs. This does not remove support from the D3D API nor does it remove support from drivers, it merely disallows mixing newer SM 6.10+ features with Work Graphs freezing the feature level at SM 6.9.

https://github.com/microsoft/hlsl-specs/pull/918

https://microsoft.github.io/hlsl-specs/proposals/0018-work-graphs/

Screenshot_20260901_044609_Opera.jpg
 
from old MS websites

MS learn website on workgraphs

Work Graphs are a system for GPU autonomy in Direct3D 12 that enables GPU-based work creation. Shader threads running on the GPU can request other work to run without waiting for that work to launch, with the system managing scheduling and memory for data flowing between tasks.​

https://learn.microsoft.com/en-us/windows-hardware/drivers/display/work-graphs

from DirectX specs for workgraphs

Here is a summary of existing ways the GPU can generate work for itself; a reminder of the breadth of work scheduling abilities GPUs already have at their disposal.​
  • Rasterizer
    • Variable number of pixels with various strict ordering requirements.
  • Tessellation and Geometry Shaders
    • Mix of programmable expansion and fixed function.
  • Mesh Shaders
    • Alternative pipeline for programmable geometry expansion and processing
    • Seeks to avoid bottlnecks in the above pipelines
  • ExecuteIndirect
    • App generates a command buffer on the GPU and then executes it
    • Many limitations on PC like not being able to change shaders
    • App needs to do worst case buffering between phases
    • Messy implementations in drivers
    • Could try to add flexibility here, but would be doubling down on the mess
  • Callable Shaders (from DXR)
    • Form of dynamic call from a shader thread that returns to caller
    • Typically implemented by ending the shader invocation at the callsite and starting a new one to resume
    • Could be extended outside DXR (even into this spec), but out of scope
    • Work graphs expose a variation on launching threads of work when return to caller isn’t needed
Work graphs exists alongside these, but can potentially also merge in some of their abilities. There will be situations where more than one of these options can accomplish a task. Unless the work to be done can be molded to very closely match the structure of one of the solutions, it is difficult to say which option is best. The answer may depend on hardware details or content characteristics.​

https://microsoft.github.io/DirectX-Specs/d3d/WorkGraphs.html
 
You must log in or register to reply here.
Back
Top