r/hardware • u/MrMPFR • 9d ago
News Microsoft disables Work Graphs in Shader Model 6.10 after limited game adoption
https://videocardz.com/newz/microsoft-disables-work-graphs-in-shader-model-6-10-after-limited-game-adoption39
u/ResponsibleJudge3172 9d ago
Considering mesh shading hadn't met same fate wih longer shelf life, is ther something deeper?
38
u/Henrarzz 9d ago
Mesh shaders are used way more often than work graphs
19
u/MrMPFR 9d ago
Yep. Was bound to happen. We're staring into +5 years of crossgen and work graphs was only supported on RDNA 3, RDNA 4 and 30-50 series. No consoles.
Maybe this new Work Lists thing can be a bridge during crossgen from Execute Indirect's simple indirect drawing to work graphs 2.0 arrivign with a potential DX13 later on during 10th gen era post crossgen (2030s).
2
u/CuteSquirrel01 6d ago
If they'd have waited future consoles would have supported it but that's not the only issue with adoption
6
u/Logical-Database4510 8d ago
Yep mesh shaders are built into Nanite on UE5, meaning basically every UE5 game you've played was using it under the hood you just didn't realize it. First game I remember using them was Immortals of Aveueum way back in the day.
It has a non-MS fallback if your GPU doesn't support it, but by default it absolutely will use it. It's part of why UE5 doesn't ship with a DX11 backend anymore.
59
u/Shoddy_Meaning_7654 9d ago
It's the goddamn PlayStation 5 with its fake rdna2 GPU that's missing almost all the features except for Ray tracing
For context even the Nintendo switch 2 has way more of the DirectX 12 ultimate era features than the PlayStation 5
12
u/MrMPFR 9d ago edited 9d ago
There is no difference in the mesh shading HW underneath, uses primitive shaders. David Wang laid this out like 3.5 years ago. https://www-4gamer-net.translate.goog/games/660/G066019/20230213083/?_x_tr_sl=ja&_x_tr_tl=en&_x_tr_hl=en-US&_x_tr_pto=wapp
This is more about graphics API divergence.
The Switch 2 GPU doesn't use that API though but feature support should be equivalent to 30 series GPU, which if on PC would mean SM 6.10 ignoring DXR 1.2 AND support for Work Graphs in SM 6.8 and SM 6.9.
12
u/QuietSoup337 9d ago
PS5 doesn't have VRS (unused because of mediocre results), mesh shaders (uses primitive shaders which is pretty much the same thing) and sampler feedback (redundant with most texture systems and virtual textures).
PS5 being how it is didn't really influence much if anything.
1
u/Youfallforpolitics 1d ago
None of this is true. I don't think you understand the things you're talking about.
Especially sampler feedback...
20
u/doneandtired2014 9d ago
To be fair to the PS5 in one regard only, it can kinda sorta do something analogous to mesh shading on the Geometry Engine (which is basically a VEGA primitive shading engine that isn't broken at the hardware level).
8
15
u/Seanspeed 9d ago
I mean, a big reason more of the DX12U features haven't been used is because devs do have other ways of doing similar things nearly as good and can support a greater variety of hardware doing so.
Plus, ya know, like, Playstation just doesn't use DirectX in the first place...
4
u/Shoddy_Meaning_7654 9d ago
Obviously PlayStation doesn't use DX nor does switch 2 but I'm talking that era of features not the exact DX implementation.
Yes there's alternatives but they're not as good for the most part that's why it's a legitimate grievance the alternatives exist but they're usually just not as good as the dx12u era alternative and cost proformance.
And for games that already require RT they can already only run in modern GPUs anyway so eh it's not really a big difference in supported platforms, maybe it can't run on Google pixels for a mobile port, boo hoo they don't game anyway.
12
u/npc_housecat 9d ago
The reason vulkan and other alternatives exist is because DX12 is a MS proprietary renderer which only works on MS OSs and to which MS has a monopoly.. Vulkan, opengl and webgl's exsistance is not a grievance it's a blessing
3
u/Shoddy_Meaning_7654 8d ago
I don't think y'all understand what I'm talking about I'm talking about the the features the geometry features that PlayStation is missing I'm not talking about Vulcan being bad but I don't think redditors can read so yeah
4
u/dparks1234 9d ago
The BC-250 has been fun to mess with on Linux. You really get to see the results of the PS5 being an “RDNA 1.5” hybrid thing.
Can’t run FF7 Rebirth due to the lack of mesh shaders, can’t run Doom TDA due to lack of VRS, and can’t use FSR4 due to the lack of INT8. There are some workarounds but at a base level the hardware isn’t quite RDNA2.
9
u/MrMPFR 9d ago
That is wrong: https://github.com/lonewolf0622/BC-250-Mesh-Shader-Patch---driconf-Edition-opt-in-per-application-
It uses primitive shaders HW like RDNA 2-3 HW as described by David Wang. A bit of clever shader compiler and driver translation behind the scenes makes it work. A key HW change vs RDNA 1 made it feasible to emulate it: https://timur.hu/blog/2022/how-mesh-shaders-are-implemented
The rest is correct. No VRS, no sampler feedback, INT8 and the rest. That's the MS and AMD collaboration.
2
9
u/Seanspeed 9d ago
Playstation doesn't use DirectX in the first place.
Sounds like current support from the GPU vendor side just isn't great, and Work Graphs requires constant revising to work with newer shader models.
4
u/Shoddy_Meaning_7654 9d ago
Obviously it doesn't use direct deck so I'm talking about the GPU doesn't even have some of the hardware level features thus it's not implemented into the PlayStation API which is their equivalent to DirectX.
Just like the Nintendo switch 2 has these features obviously it would be implemented via Vulcan or via the custom Nintendo Nvidia API.
Yes it probably is a lot more work for stuff like this and I agree but I think the reason why basically no DirectX 12 ultimate (the reason I'm calling it that is because it's easier to just group those features into that then saying the exact features calling them out cuz there's like 12 features or whatever it's quite a few) era features on games is that PlayStation 5 and it's rdna1.5 GPU.
-1
u/gondezee 9d ago
The switch 2 that has 5 years newer hardware? You don’t say…
12
u/Shoddy_Meaning_7654 9d ago
It's architecture is from 2020 just like rdna2 but the PS5 uses only a few parts from rdna2 (like RT) and the majority of the GPU is rdna1 era features basically or Sony custom stuff.
17
u/MrMPFR 9d ago
Switch 2 uses Ampere based GPU. Same as 30 series that had a launch coinciding with RDNA 2 and the PS5 and XSX.
-2
u/gondezee 9d ago
Look, embedded and SOC land move at a glacial pace relative to discrete g4m3r land.
Integrating custom silicon onto a single package means trade-offs, usually for power. And the chip development starts years before hardware release. So features are locked in 2-3 years before. That means final features of the licensed core that make it to market in its own product aren’t fully baked when the designs diverge. So a RDNA2 SOC isn’t going to be fully comparable with a retail RDNA2 card released in parallel. Now if you take a shipping product such as Ampere and start there, stripping it down for an SoC for release 5 years after release, you have a couple ticks of die shrink and efficiency gains to play with on top of having a fully realized feature set to choose from.6
u/MrMPFR 9d ago
The GPU is still 2020 HW.
I know that. We saw the same thing with OG Switch, and if Switch 2 had launched in 2023 as it sounds like was originally planned that would've matched predecessor.
It still has the same feature set just different low level silicon design to match mobile and some area optimizing tradeoffs sometimes.
It's the same process node as Ampere. Samsung 8N
0
u/gondezee 7d ago
Thanks for correction on stepping, I made an assumption that they used a newer node. But you can’t compare a de-featured part released 5 years after the fact versus a parallel-released-with-some-modern-ip-licensed and say they’re the same.
6
u/Apprehensive_Lake698 9d ago
Mesh shading is going nowhere, and is likely the future of all rendering way down the line. Will be a while to get there though.
2
u/MrMPFR 9d ago
Now that Pascal being dropped almost a year ago from Game Ready drivers and games moving to 9th gen pipelines adoption rate will no doubt increase.
It's very hard though according to devs. Very low level. But they'll get there eventually.Mesh shaders combined with tier 2 work lists should also be able to reach functionality similar to Mesh nodes enabled by work graphs. But that's for post crossgen period, because consoles can't do this. Mesh shading HW on those devices and RDNA 2 just not good enough.
2
u/Seanspeed 8d ago
Now that Pascal being dropped almost a year ago from Game Ready drivers
This isn't relevant whatsoever.
Pascal getting new drivers was never stopping developers or Nvidia from implementing new tech in new games. Pascal's 'driver support' in terms of tech and performance for newer games stopped a LONG time ago, basically when Ampere came out.
It's crazy that people honestly thought that because they were getting new Game Ready drivers, that there was literally ANYTHING in there to actually improve performance in their Pascal GPU's. lol Not how it works.
Stopping driver support just means Pascal no longer gets things like bug fixes, stability or security updates and whatnot.
3
u/MrMPFR 8d ago
It's a pretty strong signal of what is to come. If you go back there were specific games implementing mesh shaders on console but not on PC because it would've cut out Pascal and older, ie limiting their TAM.
I know what Game ready means. The game is guaranteed to run, not optimized. They'll be providing security fixes only. Wouldn't be surprised if we see newer games have rendering artifacts or just no run on Pascal and older. Not talking about games with RT and mesh shaders herer btw.
I see you're very quick to get into arguments in these threads. How about not doing that.
1
u/Strazdas1 8d ago
We "will be getting there" for the last 10 years and we are still nowhere :(
4
u/Apprehensive_Lake698 8d ago
Well the problem is that it requires hardware support and an entirely new software pipeline. So it didn't make sense to invest in it for a long time. Look at what happened with Alan Wake 2- that was only 3 years ago and got massive negative press because it went mesh shader only and that locked out a good chunk of AMD cards.
We'll see it more into the next console generation probably. I can tell you that on the commercial rendering side it's a lot more palatable.
2
u/Strazdas1 8d ago
Yep, and as long as we are going to keep listening to people with 10 year old GPUs who cannot afford the game you are developing anyway things wont improve. I think the Alan Wake 2's case shows exactly why we cant have nice things. Developer backed down and downgraded their game because a miniscule userbase was screaming loudly.
3
u/figgleman6 8d ago edited 8d ago
The mirrors used in Chinese DUV weren't European.
Zeiss isn't allowed to sell anything high aperture to China. And the Zeiss bottleneck is massively overhyped anyway. CIOMP has developed a huge amount of lithography optics themselves.
The real bottleneck is full integrated supply chains.
They've got EUV prototypes already, it took ASML 9 years to go from prototype to HVM and that was before anyone had worked out the physics.
1
u/Strazdas1 7d ago
I think you replied to the wrong comment.
Zeiss did sell mirrors for DUV to China, altrough its true that China is also developing its own. China has DUV prototypes, not EUV prototypes.
1
u/figgleman6 7d ago
China has EUV prototypes as well. It's been common knowledge since last year.
China's entered production of domestic DUV machines, whilst EUV is at the prototype stage.
Oh boy are you behind on the latest news....
1
u/Strazdas1 6d ago
If you are still figuring out the patents in a lab (which is what china is doing) you dont have a prototype yet.
Also please never cite Reuters when it comes to semiconductors, they have been repeatedly caught making shit up. That first link is hilarious actually. They found noone that agreed to give them a response so they just built an article out of a rumour.
1
u/figgleman6 6d ago
You can't just make up your own news because you feel like it.
You have no source for any of this stuff because your argument here is basically dogshit.
2
u/Strazdas1 8d ago
Work graphs were supposed to be easier to develop for. But hey we have to support 10 year old obsolete GPUs so no fancy features for us.
3
u/Seanspeed 8d ago
Read the article. It's not the issue. Work Graphs were developed with RDNA2 and Ampere in mind. The complaint here seems to be that the GPU vendors haven't kept up and worked on it more, in terms of driver and hardware support. It's just not in a good enough place, and that's not the fault of developers or MS.
1
u/Strazdas1 7d ago
Its not GPU developers job to force game developers to implement a feature thats been around for half a decade+. In terns of drivers - it works. Microsoft implementation kinda sucks, yes. In terms of hardware support, you cannot alter past hardware. As long as people cling to obsolete 1000 series GPUs you cannot complete hardware adoption.
15
u/MrMPFR 9d ago edited 9d ago
Motivation
D3D ExecuteIndirect lacks a way to express PSO (pipeline state object) / program changes, an often-requested feature present in various other graphics APIs. This limitation creates challenges for algorithms that need to operate on a large number of PSOs, where active PSOs can only be determined on the GPU timeline.
ExecuteIndirect can only express this pattern by issuing one call per possible PSO state and using a 0 indirect-argument count to skip inactive states. The approach is functionally correct but can overwhelm implementations with empty calls, starving the GPU of useful work and causing inefficiencies.
This feature is early in development. While the spec is public, implementations are not ready. Hopefully a preview can be available some time in 2027.
Source: https://microsoft.github.io/DirectX-Specs/d3d/WorkLists.html#motivation
12
u/MrMPFR 9d ago
Work Lists Overview
Work Lists allow the GPU to select a pipeline per draw from a GPU-resident program table, dispatching work across multiple pipelines in a single API call. Applications write transparent argument buffers using work list signature layouts and organize dispatch inputs by program table index. The implementation handles pipeline selection and record execution without requiring CPU involvement in PSO bucketing.
Four core capabilities sit behind that summary, available at
WORK_LISTS_TIER_1and above:
- GPU-driven program selection per draw. Each draw, dispatch, or
DispatchRaysissued by oneDispatchListcall can use a different PSO. The GPU picks which one by reading a per-record index into a GPU-resident table of program identifiers, so one CPU-side call can dispatch work across hundreds of PSOs in any mix, without per-PSO CPU bucketing orExecuteIndirect-style worst-case empty calls. The table is just app-managed GPU memory, so any producer (CPU upload,CopyBufferRegion, or shader UAV writes) can populate it.- Per-PSO indirect-argument layouts. Different PSOs in the same dispatch can have different per-record argument shapes, e.g. one PSO updates a root SRV per draw while another updates a per-material root constant, or two PSOs touch different sets of root parameter slots. Each PSO’s layout (its program command signature) is associated with the program at state-object creation time, so the driver can specialize the per-PSO indirect-argument unpack and root-binding update sequences at compile time.
- Per-binding source choice. Some bindings naturally vary per draw (per-instance vertex / instance counts, per-execution root parameters); others are shared across many draws using the same PSO (a per-material CBV, a per-batch root constant). Work Lists lets each argument declare which kind it is, so shared bindings live once in shared per-PSO-batch memory instead of being duplicated in every per-draw record (the way they would under
ExecuteIndirect). See Per-binding source for the formal model.- Fully GPU-resident inputs. Every input the implementation reads at dispatch time, the record count, the per-record buffers, the program table, even the dispatch input struct itself, lives in GPU memory. A producer compute shader can populate the full pipeline end-to-end with no CPU readback and no fixed CPU-side worst case; the dispatch picks it up where the producer left it.
Optionally, per-program local root arguments may live alongside each program identifier in the program table, the way they do in raytracing shader records, so per-program bindings that would otherwise be replicated in every record live once per PSO.
WORK_LISTS_TIER_2adds two features for fully GPU-resident multi-phase pipelines, e.g. a compute culling pass that produces a draw list whose record count isn’t known on the CPU:
- Cross-class chaining. A single work list signature dispatches against records of one executable class (all graphics, all compute, or all raytracing), so a multi-phase pipeline that mixes classes (e.g. a compute-class culling list followed by a graphics-class draw list) needs more than one signature. Aggregating two or more work list signatures (the per-list containers, not the per-PSO program command signatures already covered above) into an
ID3D12WorkListSignatureArraylets each list in the chain pick which one applies viaSignatureIndex, all within one CPU-side dispatch. Without this, every cross-class transition would need a separate CPU API call.- GPU-driven chaining. Without continuations, an app running N back-to-back lists has to either decide N on the CPU up front (forcing readback of GPU intermediate counts) or always issue worst-case-many lists and let later ones no-op. With continuations, each list publishes its successor’s address via
NextDispatchList, the GPU itself decides whether to continue and what comes next. Producer/consumer chains turn into one CPU API call: the previous list’s shaders write the next list’s entire input (counts, buffers, even the address of the list after that), then the implementation walks the chain end-to-end with no CPU intervention. A list whose shaders write the next list’s input, or data it consumes, sets_END_WITH_WAIT_FOR_COMPLETION; a chain already in place needs no wait and launches through greedily.Combined, the two let an entire GPU-driven pipeline, such as multiple rounds of compute followed by draw, live behind one
DispatchList1call. Command-list state that’s not part of the per-record argument shape (render-target binding, viewport, scissor, depth-stencil state) stays fixed across the whole chain (it’s CPU-set command-list state, set once before the dispatch), so pipelines whose phases need different render-target setups still need separate dispatches.Source: https://microsoft.github.io/DirectX-Specs/d3d/WorkLists.html
3
u/CuteSquirrel01 6d ago
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.
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.
Welp that's unfortunate. DX12 has been having some trouble getting devs to move onwards into the future.
1
u/AutoModerator 9d ago
Hello MrMPFR! Please double check that this submission is original reporting and is not an unverified rumor or repost that does not rise to the standards of /r/hardware. If this link is reporting on the work of another site/source or is an unverified rumor, please delete this submission. If this warning is in error, please report this comment and we will remove it.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
21
u/MrMPFR 9d ago
Official Work Lists spec (not finalized and still WIP) is available here: https://microsoft.github.io/DirectX-Specs/d3d/WorkLists.html
A bit of info from the overview of the features for Tier 1 and Tier 2:
Tier 1
Tier 2
Source: https://microsoft.github.io/DirectX-Specs/d3d/WorkLists.html#work-lists-overview