In Rys video you see @7:30 the VS Shader Stage is activated. But if you listen to 0x22h normaly everything which is going to rdna2 should not have VS Shader activated. Compare the picture from the Top wit the Video @7:30. At the picture you dont se VS Shader but PrimS Shader. In the Video you don't see PrimS Shader but VS Shader.
AMD Radeon RDNA2 Navi (RX 6500, 6600, 6700, 6800, 6900 XT)
In Rys video you see @7:30 the VS Shader Stage is activated. But if you listen to 0x22h normaly everything which is going to rdna2 should not have VS Shader activated. Compare the picture from the Top wit the Video @7:30. At the picture you dont se VS Shader but PrimS Shader. In the Video you don't see PrimS Shader but VS Shader.
He's looking at the profiler view and in one picture the wavefrom occupancy shows PrimS Wavefronts and in the video for DXR it only shows VS and GS Wavefronts, so he's speculating that primitive shaders are not working with DXR.
Edit: The thing is, in the video he's selected a dispatch rays event, which is not going to have any vertex or primitive shaders. So the wavefront occupancy chart may not show it because there aren't any. The selected event is 100% compute shader wavefronts. If it was a vertex shader event, maybe it would update the graph and show PrimS Wavefronts. I don't have any experience with the profiler to know the behaviour.
Last edited:
Too conspiracy-y for me. I'm sure at worst game devs will spend more time optimizing for one architecture than another, but I doubt they'd deliberately tank performance at the whim of Nvidia or AMD.
That version of RGP isn't showing PrimS. Maybe it was dropped to only show the API shaders.
FWIW primitive shaders versus legacy pipelines is a driver decision, they work perfectly fine on Navi 10. With the smaller GPU you were often just not geometry limited enough to get any benefit out of it. However on Linux the drivers like to use primitive shaders but just didn't enable the shader based culling in most cases, depending on the existing HW based fixed function culling.
Another thing is that while mesh shaders remove most of the geometry pipeline in most APIs, the hardware implementation in RDNA2 uses primitive shaders. As such there isn't really any hardware limitation that you're skipping. What is enabled though is a programming model where the application gets more space to do smart stuff with e.g. vertex data encoding.
Furthermore the other part of the D3D mesh shader feature is amplification shaders (task shaders in nvidia language) which really enable high level culling or other adjustments of the amount of geometry. (pipeline is : amplification shader -> mesh shader -> pixel shader) This is where you're really losing the ability to integrate neatly with a legacy pipeline. Not quite sure how these are implemented in RDNA 2 though. Looks like a plain old compute shader running in a compute ring that writes to a ringbuffer triggering mesh shader dispatches.
Another thing is that while mesh shaders remove most of the geometry pipeline in most APIs, the hardware implementation in RDNA2 uses primitive shaders. As such there isn't really any hardware limitation that you're skipping. What is enabled though is a programming model where the application gets more space to do smart stuff with e.g. vertex data encoding.
Furthermore the other part of the D3D mesh shader feature is amplification shaders (task shaders in nvidia language) which really enable high level culling or other adjustments of the amount of geometry. (pipeline is : amplification shader -> mesh shader -> pixel shader) This is where you're really losing the ability to integrate neatly with a legacy pipeline. Not quite sure how these are implemented in RDNA 2 though. Looks like a plain old compute shader running in a compute ring that writes to a ringbuffer triggering mesh shader dispatches.
NightAntilli
Newcomer
Well... Maybe... But there is something to it. We do have the history of x64 tessellation.
If you take the Witcher 3 for exmaple, there is marginally any difference between x8 tessellation and x64 tessellation, and with x16 tessellation it was pretty much identical. Yet, HairWorks was "optimized" for x64 tessellation. AMD was weaker at tessellation at the time, so their performance dropped a lot, even though such huge performance drops were not necessary on either vendor's cards. Would it be too conspiracy-y to say that this was done on purpose, especially since there is no visual difference between x16 and x64 and nVidia had an advantage over AMD in this specific tech...?
nVidia is always in these controversies. What's funny is that one of Buildzoid's first comments about the 6800 series, was him wondering if nVidia would figure out a way to overtax or overflow the infinity cache so that performance on these 6800 cards crash.
I like all the open standards AMD goes for, and how they publish a lot of stuff for free for developers. Ultimately it does seem like a disadvantage for them in certain cases, like how TressFX was hijacked and rebranded as PureHair for example.
Still sorting out things. Don't want to post misleading numbers. Sorry it's taking so long.
D
Deleted member 2197
Guest
Does AMD have another category of gpu's for prosumers that haven't been released yet?
Gameworks titles are continually decreasing in number so at least we are getting less and less of Nvidia’s shenanigans.
D
Deleted member 2197
Guest
They are currently integrated with Unreal engine and seems developers use Flow, WaveWorks, Blast, Volumetric Lighting, FaceWorks and a few others that are currently open source and run on AMD hardware ( and Intel likely). Unless there is a perceived value by not open sourcing (like Radeon Rays), I imagine most will transition to github over the next few years.
Last edited by a moderator:
Frenetic Pony
Veteran
.
Most of these aren't used at all, at least on anything you've actually heard of. They're shiny and stuff but apparently when you try to actually use most of it the whole thing becomes impractical and devs are better off with other solutions, or UE does it better already anyway.
Not that AMD is getting off this train either. Not only is Godfall's raytraced shadows an AMD thing but they're adding other such stuff. Far Cry 6 already announced a partnership with AMD for raytraced reflections, and while I appreciate the neat realtime denoising and reprojection slides AMD put out (which Watch Dogs Legion could really use, etc.) it still wouldn't surprise me if it didn't run the best on Nvidia or some such.
I really wish game dev companies would treat their developers better and pay them more. It seems like a large number of high end graphics devs have left for Nvidia or possibly AMD; if they haven't left for Epic or Unity already. At least at the last two they'll actually produce games; and not stuff like "RTX GI" which can end up like the above. Seemingly a good idea until you actually look into it and realize you can't just plug some highly integrated, complex solution into your own custom engine without a good amount of work that could be used to make your own similar solution that works better for your title anyway. (Sorry RTXGI guys)
Most of these aren't used at all, at least on anything you've actually heard of. They're shiny and stuff but apparently when you try to actually use most of it the whole thing becomes impractical and devs are better off with other solutions, or UE does it better already anyway.
Not that AMD is getting off this train either. Not only is Godfall's raytraced shadows an AMD thing but they're adding other such stuff. Far Cry 6 already announced a partnership with AMD for raytraced reflections, and while I appreciate the neat realtime denoising and reprojection slides AMD put out (which Watch Dogs Legion could really use, etc.) it still wouldn't surprise me if it didn't run the best on Nvidia or some such.
I really wish game dev companies would treat their developers better and pay them more. It seems like a large number of high end graphics devs have left for Nvidia or possibly AMD; if they haven't left for Epic or Unity already. At least at the last two they'll actually produce games; and not stuff like "RTX GI" which can end up like the above. Seemingly a good idea until you actually look into it and realize you can't just plug some highly integrated, complex solution into your own custom engine without a good amount of work that could be used to make your own similar solution that works better for your title anyway. (Sorry RTXGI guys)
Ya gameworks thankfully is mostly relegated to budgetware few people will ever play. AMD tech typically fares fine on Nvidia cards. TressFX(required 1 patch that came very shortly after launch) and PureHair for example ran fine on Nvidia GPUs.
Last edited:
D
Deleted member 90741
Guest
MS or Sony is going to buy them all so there is that.
D
Deleted member 13524
Guest
There are no Radeon Pro cards based on Navi2x.
Regardless, those results stem from unoptimized drivers, particularly considering the fact that the 6800XT is getting barely 30% above the 5700XT in most cases.
yes but it happened before. And by before I mean as little as 5 years ago.
DegustatoR
Legend
What would Nvidia s/w engineers do without GPUOpen? There are no other ways of finding out how to tank a publicly available GPU performance.
D
Deleted member 2197
Guest
AMD Radeon RX 6900 XT Geekbench OpenCL score leaks
AMD Radeon RX 6900 XT Geekbench OpenCL score leaks - VideoCardz.com
Yes, hopefully AMD also allows slightly more Power limit for OC, as that 15% is holding this chip quite badly ...
We had a 6900XT example before here, running at 3ghz. essentially a +30TF full fat RDNA2 GPU with 128mb infinity cache. Sounds like a damn impressive GPU to me. Yes ray tracing isnt what Turing and ampere do, but at those speeds and amount of CU's, it could be good enough for many. 6800 might be so-so in RT; but a 6900XT at those speeds?
RDNA3 is where things start to be even more intresting i think. NV is going to have to work if they want to stay ahead next year.
