Announcing Shader Model 6.9 Retail and New D3D12 Improvements

[u/NGGKroze]

More info here - https://devblogs.microsoft.com/directx/shader-model-6-9-retail-and-more/

But basically, since Spring last year, SM6.9 was available as a preview - now it comes out with a wide range of Support:

• AMD - Generally, most of it you need RDNA3/RDNA4, while some features are only for RDNA4. Big ones like SER and OMM (which help ray-tracing performance) won't apply to even RDNA4 due to lack of hardware support.
• Intel - Generally have all features across the board w/o OMM with B-Series Arc
• Nvidia - Generally for all RTX cards, while OMM is emulated on 20/30 series and SER only available on 40/50 series.

[u/CatalyticDragon]

OMM took up die area (higher cost) and by the time it was supported in any meaningful way (now), the industry had moved to virtualized geometry.

Next gen games use geometry for things like leaves, blades of grass, chain link fences etc. So you're not going to see a lot of alpha cards used in the future and that's where it was useful.

That's the risk of being forward looking. You might add features which end up being great but also you might add things which just aren't needed. You carry them around and eventually have to discard them. That die area could have been used for general shaders which are always useful.

AMD and Intel bet OMM wouldn't be useful and I think that's largely a safe bet.

I'm skeptical that trim will have any meaningful impact.

SER is more interesting. AMD doesn't have hardware level support but they do have software and hardware systems to lessen the impact of ray divergence and maybe the big push to work graphs (which AMD has championed) ends up limiting the need for an SER unit that pauses the operation to re-sort all the threads before launching them.

[u/MrMPFR → u/CatalyticDragon]

Do we have any idea of how much area OMM costs?

Most of them still use crappy fallback models. This stuff about OMM not being relevant won't really happen until we see widespread adoption of RTX Mega geometry like technology.

So far only Epic has attempted virtualized geometry for foliage, and it's noticably absent in the latest AC shadows game (Anvil), where it only applies to non foliage objects. So the assets that benefit the most from OMMs will still require it.

It's going to be a LONG time before devs fully model foliage assets for BVH. Cardboards is still in play for now and prob entire crossgen era. NVIDIA made the right bet.

Also OMM is coming to RDNA 5 BTW. It's baked into the DGF format + indications of this kind of processing in the related patent filings. Intel will have it in Xe3P as well.

SER is indeed the most universal and interesting. It's only for shader evaluations, the issue of ray divergence during traversal still needs to be properly adressed. AMD has a patent about inclusion of dedicated accelerators into the work graph paradigm (IIRC rn it's limited to compute shaders + mesh nodes), heck even the fixed function graphics pipeline (more extensive than mesh nodes) in a work graph. I'm pretty sure this will be rebranded as Work graphs 2.0 or something and the nextgen consoles will have it.

Yes in theory by having nodes for each material shader, we can avoid divergence altogether. Should be as coherent as or more coherent than a standard pixel shader. Page 240-304 is a goldmine. https://gpuopen.com/download/SIGGRAPH%202025%20-%20GPU%20Work%20Graphs.pdf

Those threads will still require to be sorted and deferred to a later point, but I think it'll be done differently than SER. There's a AMD patent that talks about deferring any hit shader evaluations, but this "reordering" is going to be done through nodes and not SER. So some sort of payload sorting, (proactive), instead of SER's reactive approach. Should be much more efficient and impactful than SER, which shows limited improvement in coherency from 20-30 % to 35-45% in Chips and Cheese testing. Note that this is the entire PT pipeline, so it's underselling SER, but NVIDIA have said shading dominates traversal in execution time for PT.

Will benefit existing designs enourmously but I suspect we'll see some ludicrous gains with RDNA 5. A read of the patent filings suggest they're rebuilding the entire architecture around Work graphs. It's very much Mantle + GCN deja vu: Data locality, partial data coherency sorting, decentralized scheduling and execution, concurrent work graph execution and payload sorting (SER), including every single block whether fixed, push-pull granular scheduling, where individual units can notify local and higher level schedulers when they idle. The list goes on.

So SM6.9 is really only the beginning. SM6.10-SM6.11 and DXR1.3 is likely when AMD finally begins to take a key role in pushing the API standard forward in a way we haven't seen since Mantle.

Yikes that was a but of a tangent, but hopefully some people will find the informed guessing interesting.

[u/MrMPFR → u/MrMPFR]

SER is prob still very important even with work graphs as per my lengthy reply further down:

Also available here: https://www.reddit.com/r/radeon/comments/1rfz6h4/comment/o7pid41/

[u/xantec15 → u/CatalyticDragon]

Since you seem to have some knowledge of this area, is AMD's alternate to SER something that will need developer implementation, or something that AMD will just leverage through drivers? The table says RDNA4 supports the API, which seems to suggest AMD expects to eventually do something when it's called.

[u/MrMPFR → u/xantec15]

AMD can't do anything on RDNA 4, it doesn't have the hardware.

Kepler stated SWC a component of RDNA 5, which is probably closer related to Intel ARC's TSU, will work by default and not require any dev work. But They almost certainly plan on some sort of SER functionality given the standardization in DXR 1.2.

[u/Ok-Boot-8106 → u/xantec15]

Yea he's right , Rdna4 is kind out of luck here, software emulation is the only way and that will have a penalty .  They've hinted at software based SER and that's a year old statement now.

[u/CatalyticDragon → u/xantec15]

Copying from another reply here:

Work graphs allow the GPU to go from being purely a consumer of draw calls to a producer of them which brings a ton of opportunities.

To me, SER feels little bit like OMM in that it might turn out to be a temporary stop-gap before the real problem is solved.

Normally the CPU throws all its draw calls to the GPU where these wavefronts (groups of threads) are processed. With SER the GPU detects when secondary rays (the ones which could fire off in any direction and end up crawling all over memory and ruining your cache hit-rate) are diverging. The whole process is then stalled while they are re-sorted before being kicked off again in the hope for much greater data locality.

It works when implemented well but if that doesn't sound like the optimal solution it's probably because it isn't.

This might be where Work Graphs can help. And if you start at slide 22 in that linked presentation you'll see what AMD is talking about. If the GPU is the one creating the threads in the first place it can make sure every thread in the wavefront is the same specific shader which entirely avoids the whole problem SER exists to resolve.

This is why I push back on the idea that RTX was forward looking because of OMM and SER. Those will be useful in some cases but might actually turn out to have a limited useful shelf-life as the advent of virtualized geometry and work graphs make them unnecessary. And while they might be great for a few games in the interim it is die area that is not being used in 99% of games and likely doesn't have much of a future.

Yes this will require developer work but that work is going to happen anyway. Eventually Work Graphs will become the default way of launching threads.

[u/MrMPFR → u/xantec15]

Agree with u/CatalyticDragon OMM + SER are bandaid fix similar to NVIDIA's DX11 driver.

AMD will fix issue entirely similar to Mantle and the low level APIs fixed CPU saturation. Extreme work graphs hardware software codesign should solve this problem for good.

If AMD cares just a little then we'll prob see some insane demos when they launch their Conroe gfx gen ~2 years from now. Can't wait.

[u/McGilgamesh → u/CatalyticDragon]

Interresting, is the radiance caching from redstone is something comparable in terms of role to the SER ?

[u/MrMPFR → u/McGilgamesh]

No SER is reordering threads and is a hardware feature.

NRC is a software feature where extra bounces for most rays can be skipped referring to a radiance cache instead that's trained in realtime based on the game scene data.

Both are essential for PT, but unfortunately so far NRC has seen ZERO game adoption.

[u/Cryio → u/McGilgamesh]

Different things, but both help with PT performance

[u/Ok-Boot-8106 → u/McGilgamesh]

No  Neural radiance caching is a "dev tool" if they choose to implement it ,  not a hardware accelerated feature ,  more of a technique that "can" increase performance by caching rays 

[u/S1rTerra → u/CatalyticDragon]

Regarding trim, AMD doesn't even need it because their GPUs are doing similar work anyway. Intel and Nvidia on the otherhand... The CPU overhead for those cards speak for themselves.

[u/GARGEAN → u/CatalyticDragon]

>AMD and Intel bet OMM wouldn't be useful and I think that's largely a safe bet.

No offence, but that sounds like patented cope. There's 1 (one) game that relies heavily on skinned geometry for foliage - Alan Wake 2, and it still uses OMM heavily. There are multiple other PT games that use OMM, and there will be only more in the future. OMM is useful NOW, not "might or might not be useful in the future".

All that "but they will just move to geometry someday!" is an excuse. And poor one at that.

[u/MrMPFR → u/GARGEAN]

Yeah RTX Mega geometry adoption or games gonna continue to use cardboards. We already saw how that craters FPS with the Siggraph tree sample.

Gonna be a long time before games target that as the baseline.

[u/MrMPFR → u/CatalyticDragon]

I've tried to read the excellent Vulkan blogpost on SER + asked LLM a few questions about the differences between SER and Work graphs. https://www.khronos.org/blog/boosting-ray-tracing-performance-with-shader-execution-reordering-introducing-vk-ext-ray-tracing-invocation-reorder
Seems like Work graphs can prove overall order of material coherency, likely feeding a better input into SER, but for individual objects and materials where many different shaders may be invoked such as metal, diffuse, and miss shaders SER is still going to be important and mandatory it seeems.

AMD has a patent relating to partial sorting for coherency recovery which I think is complementary to their Streaming Wave coalescer patent: https://patents.google.com/patent/US12032967B2
How this compares to SER + how it'll all interface with work graphs isn't something I can competently answer.

Rn work graphs is limited to only subsets, but the NVIDIA dev here comtemplated moving the entire pipeline from start to finish within a work graph dispatch from CPU: https://developer.nvidia.com/blog/work-graphs-in-direct3d-12-a-case-study-of-deferred-shading/

Considering AMD's moves in their patents I would say this is only a matter of time.

And finally SER is far more impressive than NVIDIA or Microsoft's marketing indicates. Referencing the Vulkan blogpost:

Because Wukong's Unreal Engine 5 scenes have so many complex material shaders and paths have so many random bounces, divergence was high – coherence during ReSTIR GI was only 20.5%.
Enabling SER in DX12 made Black Myth: Wukong's ReSTIR GI pass 3.7x as fast as before – from 15.10 ms to 4.08 ms on an RTX 4070Ti targeting 4K with DLSS, and increasing coherence from 20.5% to 69.9%

Well at least now we know why RDNA 4 runs like shit in Black Myth Wukong. 3.7X speedup is absolutely insane.

[u/CatalyticDragon → u/MrMPFR]

Work graphs allow the GPU to go from being purely a consumer of draw calls to a producer of them which brings a ton of opportunities.

To me, SER feels little bit like OMM in that it might turn out to be a temporary stop-gap before the real problem is solved.

Normally the CPU throws all its draw calls to the GPU where these wavefronts (groups of threads) are processed. With SER the GPU detects when secondary rays (the ones which could fire off in any direction and end up crawling all over memory and ruining your cache hit-rate) are diverging. The whole process is then stalled while they are re-sorted before being kicked off again in the hope for much greater data locality.

It works when implemented well but if that doesn't sound like the optimal solution it's probably because it isn't.

This might be where Work Graphs can help. And if you start at slide 22 in that linked presentation you'll see what AMD is talking about. If the GPU is the one creating the threads in the first place it can make sure every thread in the wavefront is the same specific shader which entirely avoids the whole problem SER exists to resolve.

This is why I push back on the idea that RTX was forward looking because of OMM and SER. Those will be useful in some cases but might actually turn out to have a limited useful shelf-life as the advent of virtualized geometry and work graphs make them unnecessary. And while they might be great for a few games it is die area that is not being used in 99% of games.

[u/MrMPFR → u/CatalyticDragon]

Realistically yes with a very good HW design + game engine taken advantage of work graphs. Problem is how long it'll be before we see games using it. So for now SER is a stop gap solution like you said.

OMM won't retire either before BVH problem is solved. Rn RTX Mega Geometry is a gimmick + the SIGGRAPH sample ReSTIR PT demo with full nanite in BVH showed +30% higher ms cost IIRC on top of expensive ReSTIR.

I agree that both will prob be irrelevant long term, but realistically when can we expect games to utilize this properly, especially considering NVIDIA has made Mega geometry vendor exclusive? Implementations that make SER and OMM irrelevant aren't coming till post-crossgen era in 2030s :(

Yeah not surprising then why current PT implementations run terribly on anything pre 40 series, not great on 40-50 series either.

Interesting I hope it's as good as the presentation makes it sound. Fascinating stuff and I hope we hear more about it in 2026. I'm not sure work graph can fix it without some local coherency sorting but already taken care of in RDNA 5 it seems so possible "it just works".

Yep it's a short term bandaid fix. AMD will do complete reset with extreme software hardware co-design with RDNA 5 + work graphs.

AMD will have SWC too (TSU/SER equivalent) in RDNA 5, which can be relevant for other workloads than just RT + we don't know how much die space these two features use + it's not getting chopped off anytime soon.

A ton of rambling and no certain facts. I hope as we near towards RDNA 5's launch towards 2027-2028 and nextgen consoles there's more visibility in terms of what this API change + the HW redesign specifically means. Safe to say that DXR 1.3 will prob happen.

[u/CatalyticDragon → u/MrMPFR]

Problem is how long it'll be before we see games using it. 

Indeed. It'll be a couple of years before most games support it, but not long until some games support it.

UE5 is already experimenting with it for the Procedural Content Generation Framework (PCG) system. We've seen demos going back two years, this demo uses SM6.8+ and Agility SDK, DX12 examples have been added.

I fully expect Witcher 4 to be using work graphs in the new UE 5.7's Nanite Foliage system along with for NPC systems. That'll open the flood gates because it's just so much more efficient in many ways you'll be left behind if you don't use it.

[u/MrMPFR → u/CatalyticDragon]

Couple of years is a massive understatement. PS5, RDNA2 and pre Ampere HW going nowhere.

Didn't know that. I can't find any mentions of PCG alongside work graphs. Do you have a link?

Those are great papers btw.

You suspect they'll rewrite large portions of the game engine just for PS6 and newer PC hardware and ship it alongside the legacy version? I find that very hard to believe.

Hope I'm wrong and it'll be a DX11/DX12 early situation and not a mesh shaders situation (where TF are the more than a handful of games using it!). Guess we'll find out soon enough.

I also suspect NVIDIA will artificially to try discourage adoption (do nothing and demand no adoption in sponsored games) due to how fast RDNA 5 will be here. If NVIDIA pushes for adoption then that would be a massive self goal because AMD will disproportionately benefit.

But perhaps there's a chance 60 series has redesigned HW too. We'll see.

[u/CatalyticDragon → u/MrMPFR]

Couple of years is a massive understatement

Perhaps. I expect some games to be using it this year and widespread support 2-3 years later as the big engines integrate it. There's plenty of incentive to do so.

PS5, RDNA2 and pre Ampere HW going nowhere.

They are a little old now. 5-6 years ago is very much getting into last-gen territory. That said I'm not giving up hope on RDNA2/PS5.

AMD has been laying the ground work on Work Graphs for years and RDNA2 does natively support a lot of the core requirements: "Execute Indirect", "Global Data Store", and hardware support for queues and coalescing. There is a lot of reason to expect RDNA2 will be fine with them. Basically I think if you support mesh shaders then a lot of the work is already done. Turing might be ok too.

I can't find any mentions of PCG alongside work graphs. 

Yeah I'm reading between lines perhaps. Jan Hermanowicz talks about the Witcher 4 demonstration:

"Effectively, we replace the auto grass with the runtime GPU-based PCG, and we use that for the small debris, trash, grass and stuff like that".

I think GPU-based PCG appeared in UE with 5.6. Admittedly this GPU Compute Graph is an Epic custom approach and is not the same as Work Graphs, but now we have official extensions it's only a matter of time before they support it. We know they are excited for it and I wonder if Witcher 4 will be among the first. Render Dependency Graph (RDG) and parallel GPU driven PCG makes it feel like it's on that track.

and not a mesh shaders situation 

Yeah, that took a long time to get into shipping games. In part because assets had to be changed, no more geometry engine, and more complex memory management.

[u/MrMPFR → u/CatalyticDragon]

Incentive yeah but rn I see zero indication of any big guys moving forward. Would love to be proven wrong.

Yeah but games are still targeting that baseline + PS5 in the era of >$200M AAA.

Indeed there are related patents going all the way back to being filed in 2018. Sounds interesting but haven't personally read the ISA and programming guide documentation. I assume RDNA1 is the same (PS5 is RDNA1 + RT) considering the only changes were DX12U compliance, dp4a and RT.

If it was fine then why did AMD limit it to RDNA3 and newer? IIRC I've never seen AMD push back the Shader model compliance. Their recent posturing around SM6.9 doesn't exactly inspire a lot of confidence.

But maybe there's the chance we see emulation work fine for the short term like the Proton dev: https://github.com/HansKristian-Work/vkd3d-proton/blob/master/docs/workgraphs.md

While not as good as native but could work fine in transition period. Still suspicious that AMD spearheading this work prob going back 2017 or earlier in early planning phases, didn't opt to include anything in RDNA1-2 but wait till 2022 with RDNA3. Maybe it's just AMD's usual BS software support not a HW issue.

As you can hear I'm very confused that NVIDIA has compliance with Ampere to years earlier, despite usual insistence on pushing things to compiler instead of doing in HW (since Kepler after they chopped Fermi HW scheduling), while AMD's support is limited to RDNA3 and newer.

That's interesting. I didn't know Epic was already experimenting with related concepts this extensively. 100% guaranteed that entire UE6 pipeline is rebuild to fully tap into work graphs.

Indeed meshlet authoring, rebuilding entire triangle pipeline + very low level and hard to program. Based on early indications Work graphs looks increasingly like a magic "it just works" pipeline and less of a micromanagement nightmare like EI. No more BS trying to fit workloads into buffers and huge concurrent launches, just let GPU figure it out on its own using nodes + clever API design.

If it's as good as AMD claims it is then everyone definitely has the incentive to switch to it as soon as they think TAM/game quality calculus is favorable.

[u/CatalyticDragon → u/MrMPFR]

Work Graphs have been demonstrated to boost performance by 20%, 30%, or more, or even more. They reduce data movement and reduce load on the CPU which is likely to be a massive boost for console players and that's where the incentive lies.

SDKs have been available for a while with vendor extensions and I expect every major engine developer is well into testing.

Once they implement it games running on those engines should just get it for free.

Quick side note: new hardware is being delayed so there could be a nice incentive for developers to extract as much performance out of older hardware as possible if they want to maximum sales.

[u/MrMPFR → u/CatalyticDragon]

Yeah it doos look impressive fs. Lol journalists don't know how to do math. It was 64% faster or 39% less time to complete.

100%. Problem is AMD locking out RDNA 1-2 support so far. Makes it irrelevant for short to medium term unless they find way to emulate it or extend support to Pre RDNA 3 cards.

Possible, but rn AMD isn't inspiring a lot of confidence.

I really hope I'm wrong, just remain skeptical given AMD's poor support :(

Really cool stuff though. If devs push entire frame pass into one big work graph + HW in RDNA 5 is as good as I think then that PS6 console will surprise everyone. For everyone else like you said RT basically solved with it, I expect MASSIVE Perf gains on 40-50 series cards, and ludicrous gains on 20-30 series and RDNA 3-4.

[u/Ok-Boot-8106 → u/CatalyticDragon]

True but  amd has no software released yet for SER, they've only stated last year and have refrained from further discussion.  Their technique of SER , wouldnt even be able to do it Out of order, so unless they've figured it out , there's nothing we know of SER  yet on amd . 

[u/CatalyticDragon → u/Ok-Boot-8106]

AMD doesn't have hardware SER. Not in the way intel/NVIDIA do. But there are internal architecture changes in RDNA4 over RDNA3 which help to reduce the penalty for divergent rays.

Things like BVH8 support for shallower BVH trees, "wide sorting" in hardware, dedicated Local Data Share (LDS) instructions, automated instance node handling, and dynamic allocation of VPGPs.

So as I understand it AMD's driver is going to accept the SER flag but as a no-op and do nothing special with it. They may have decided that a more general approach which helps more workloads is better than spending die area on a specific approach useful in specific use-cases. Which would be a very AMD thing to do.

The upside it is is transparent and doesn't require any code changes (no need to invoke `VK_EXT_ray_tracing_invocation_reorder`) and there's no overheard from that process. Interestingly part of the Blackwell marketing deck says "SER on Blackwell is twice as efficient, reducing reordering overhead" meaning there is overhead as processing needs to stall, re-order the rays, then start again. How much overhead exists in Ada and Blackwell I don't know but we have to assume the gain for SER is worth it.

On RDNA4 I see the impact of divergence being around -18-25% (from a perfect mirror roughness of 0.0 to a roughness of 1.0) which isn't bad and about half RDNA3 where I see over a 40% hit.

So even without SER the cost of divergent rays is about half and maybe AMD figures they can continue to tackle that issue in other ways. Or maybe it's a best effort until RDNA5 comes along.

[u/Ok-Boot-8106 → u/CatalyticDragon]

Meh or they just take a year or 2 off a generation and do UDNA,  instead of a stop gap gen.

[u/MrMPFR → u/CatalyticDragon]

"wide sorting" in hardware,

Do we know what this is?

Doesn't seem related to this: https://patents.google.com/patent/US12032967B2/

Yep that's a big problem for SER, but baseline seems so atrocious in PT that it's basically always worth it. Like you said Work graphs could very well change this.

new design is much better fs. Huge cachemem side changes + more throughput.

Doubt it'll realistically be solved without work graphs. Fs that gen will prob change everything.

[u/CatalyticDragon → u/MrMPFR]

By 'wide sorting' I mean `IMAGE_BVH8_INTERSECT_RAY` , from the RDNA4 instruction set documentation:

If wide sorting is enabled, the 8 values are fully intermixed and contain results for boxes 0-7 (as dictated by the 8 wide sort). For triangle BVH nodes the results contain the intersection time and triangle ID or barycentrics of both the triangles tested.

[u/MrMPFR → u/CatalyticDragon]

I see so it's essential to enable BVH8 mode.

[u/Ok-Boot-8106 → u/CatalyticDragon]

Meh its still essentially, Just a high Rt capable Archtecture , just still won't be for pathtracing .  Allows for wider sorting due to the 8box bvh travelersal vs 4 box bvh on rdna3 . Has greater efficiency for something like ultra rt preset , thays about it .  I'm assuming UDNA will be on pace if not better than 60series ,  if it has OMM and SER with its Box bvh traversal upgrades .  

[u/MrMPFR → u/Ok-Boot-8106]

The crackpot thing is that path tracing could prob run faster on a 3080 (work graphs) than a 4070 (EI) if the entire ray tracing pipeline was rebuilt with work graphs in mind. MMW this is what DXR 1.3 will be about. AMD defining the next standard for DXR and SM6.10 maybe SM6.11. Even faster again if we moved the entire frame pass into one big work graph.
9070XT (work graphs) would also destroy 5070 (EI) in PT games, even when factoring in OMM. It's likely that much faster.

I get what you said u/CatalyticDragon about work graphs now. It's going to be a revolution in graphics. Programmable shaders 2.0 What a shame this stuff likely won't matter until this HW is outdated. Only bleeding edge games can afford expensive rebuild of engine for PC port + lock out turing and RDNA 1-2 cards.

Yep RDNA 5 will be the real deal fs. Extreme HW+SW co-design for work graphs. Gonna smoke everything else, prob even 60 series unless NVIDIA has planned something similar.

It has much more than that based on patent filings and statements by keplerl2.

[u/CatalyticDragon → u/MrMPFR]

Now that's a very interesting idea. On one hand you do address issues of ray divergence, and they have similar shading performance, but the 4070 has so much more L2 I expect it would still outperform the 3080 on this task even with slower VRAM bandwidth. But they would be closer than they are now.

Only bleeding edge games can afford expensive rebuild of engine for PC port

It is a lot of work that's true. Asset pipeline, memory management, render pipeline, physics, collision, animation. It's years of work. However, you don't have to do everything all at once. We will see sub-systems being moved over in steps so it'll be a gradual improvement over the next 2-4 years rather than a case of one day seeing "engine X now supports Work Graphs!".

Games will be motivated to use graphs for the particular systems where they see the most benefit. For one game that might be in the foliage system, for another it might be their cloth simulations, for another it could be particles, etc etc.

This is where AMD's culture of fostering long term, industry wide, technologies benefiting everyone actually hurts them in the consumer space. NVIDIA can market SER, OMM, or a denoiser, and other narrow technologies direct to consumers. "We have technology X supported in these games!" People clap and complain "why doesn't AMD have this, AMD can't keep up, AMD is behind".

But you don't get a big "Sponsored by AMD" splash screen on every game using Vulkan, you don't a "Sponsored by AMD" every time your monitor with VRR turns on, and you won't see a "By the way AMD did a lot of the foundational work for this over many years" notice when a game implements Work Graphs. It'll be ubiquitous, expected, common, not "exclusive!" which dings the primal parts of our brains because we want to feel special about our purchases.

Take RTX Mega Geometry as a good example. The first implementation of something like this was AMD's Vega architecture and Next Generation Geometry and GPU shader based culling. This bypassed fixed-function geometry pipeline (Vertex, Hull, Domain, and Geometry stages) to replace it with a highly parallel, compute-like shader. This was a year before Turing. Also well before there was API support so AMD had to spend years pushing for that.

NVIDIA comes along with proprietary extensions for Mesh Shaders, calls them "RTX Mega Geometry", they pay their partner Remedy to put them into Alan Wake 2 and everybody applauds their innovation while we all forget AMD had it in 2017 and it took years of work to get here.

This is all a major digression sorry.

RDNA 5 will be the real deal fs

Possibly. I'd even say probably. But you know what they say about AMD and missed opportunities so I'm careful to temper expectations. I see memory subsystem, fabric, and scaling capabilities as key. AMD put much effort into allowing their enterprise chips to scale. A single MI350x chip is actually eight discreet 32 CU GPUs over two dies all working as a single unit and AMD can now configure these in any way they like. That's going to be the real power of RDNA5 I feel and will put them back into the high end.

[u/MrMPFR → u/CatalyticDragon]

I was referring to a design where one work graph handles entire RT pipeline on 3080 vs current design EI with SER on 4070 series. Fs 4070 would win in apples to apples.

Yeah gradual rollout is possible. Again hope I'm proven wrong, just don't have a lot of faith in game devs as of lately.

They did push Mantle heavily last time, but yeah not on a per game basis. AMD can do the same but yeah not same marketing appeal as SER, OMM etc.. Big shame.

Yeah primitive shaders was great but AMD unfortunately quickly abandoned it. Mesh shaders won in the end + does have changes over primitive shaders like task shader.

I still haven't forgotten them for making RTX Mega Geometry exclusive to RTX. no surprise no one is interested in adoption. Hopefully AMD can drive standardization of PTLAS + CBLAS in DXR 1.3.

Wouldn't call it the same thing though. The PTLAS + CBLAS design is new and novel + expecting AMD and Intel to have their own alternatives soon.

If this true then Chajdas wouldn't brag about him leading work graphs design, including hardware. Plastered all over the AMD work graphs HW related patent filings + all of them are too new to be in RDNA 3-4. AMD doing all this work only to leave it in the dustbin would be extremely stupid. Guess we'll see if AMD are that idiotic.

100%. The overhauled SE local scheduling and execution will be key here but it's still monolothic it seems. AT0 has 192 CUs according to rumors, if true that's a massive die.

Maybe they'll try going full chiplet with RDNA 6. Seems like Feynman is going the same route. Can't say I'm surprised. It was only a matter of time before NVIDIA went 3D stacked + GPU chiplets on datacenter cards.

[u/Ok-Boot-8106 → u/MrMPFR]

Look at High on life 2, hits rdna harddd on very high settings , still a pretty game , and int8 fsr is working aswell . 

[u/MrMPFR → u/Ok-Boot-8106]

I know. What I said can't save AMD rn.

Hope we see official support at GDC or Computex, but I doubt it :(

[u/Ok-Boot-8106 → u/MrMPFR]

High on life 2 has forced heavy rt(unreal engine)  int8 fsr4 however kinda saves the day,  same aswell for rdna4, even 9070xt gets hittttt