AMD Radeon RDNA2 Navi (RX 6500, 6600, 6700, 6800, 6900 XT)

I tried enabling 4G decoding on my x470 motherboard, it works fine if CSM is enabled and causes bsods if it's off and internal MoBo audio is disabled. Also, in the recent AGESA 1100 bioses that were released by Gigabyte few days ago, there's a hidden option "resizable BAR support" which gives hope that it can be enabled on non-Zen3 CPUs and non-5xx series boards.
 
AMD Radeon RX 6800 XT RDNA 2 Graphics Card 3DMark Time Spy Extreme Benchmark on Par With NVIDIA's GeForce RTX 3080

The user who had got early access to the AMD Radeon RX 6800 XT reveals that the graphics card scores around 8500 points in the 3DMark Time Spy Extreme benchmark. The GeForce RTX 3080 stock graphics card scores around 8900-9000 points in the same benchmark (graphics score) that puts the RX 6800 XT on par with NVIDIA's $699 US offering. The Radeon RX 6800 XT will be retailing at $649 US which is $50 less than the GeForce RTX 3080.

Read More: https://wccftech.com/amd-radeon-rx-6800-xt-3dmark-time-spy-benchmark-on-par-with-rtx-3080/
 
AMD Radeon RX 6800XT – BIOS reveals new details about Rage Mode, Turbo Mode and Silent Mode
Looking at the code, four modes stand out. Quiet and balance, rage and turbo. This presetting is implemented via the power limit, the target temperature and the fan control with Acoustic Limit and Target (RPM). It’s interesting here that Turbo Mode, which AMD didn’t talk about at all, is even a bit more aggressive. I am already happy that it has not been called Uber Mode again. If you now look at the 95 °C limit for the temperature in the MorePowerTool (MPT), you can almost get scared, because fireflies are not really trendy seasonally.

It seems as if the board partners have a free hand when determining the fan parameters, since they know their coolers and their performance (including possible reserves) best, but the power limit of +6% as a premium was probably given as a guideline or can be found in other BIOSes purely by chance. But in the end, these modes do nothing else that you could not have done since the release of MorePowerTool MPT.

A reference card with the officially stated 300 watts would then be with Rage Mode at the almost 320 watts I extrapolated and the board partner card shown above in the MPT would be far, far above that. Let’s be surprised, I promised you a hot autumn. At least this one is currently available and can be plugged in.
https://www.igorslab.de/en/amd-rade...ar-mode-turbo-mode-and-silent-mode-exclusive/

 
I fear for Cyberpunk to be honest. CDProjekt Red has a history of using nvidia-centric optimizations that hurt performance on AMD GPUs, like Hairworks on Witcher 3.

Looks like Cyberpunk is cleared.

https://wccftech.com/nvidia-interview-discussing-ray-tracing-support-and-proprietary-extensions/

What ray tracing games are out now that use NVIDIA proprietary technology?

Brian: The vast majority of games released with ray tracing support use the industry standard Microsoft DirectX Ray Tracing (DXR) API. Three exceptions we are aware of include Quake II RTX, Wolfenstein: Youngblood, and JX3, which use NVIDIA ray tracing extensions for Vulkan.

(...)

I have seen stories that say that Cyberpunk 2077 ray tracing will only work on NVIDIA GPUs. Why is that?

Brian: Cyberpunk 2077 uses the industry standard DirectX Ray Tracing API. It will work on any DXR-compatible GPU. Nothing related to Cyberpunk 2077 ray tracing is proprietary to NVIDIA.
 
Any power-of-two up to the max supported by the PCIE spec. AMD GPUs going at least as far back as GCN1 (GFX6) support both 64-bit BARs and BAR resizing
Thank you for clarifying this - BAR Size can still be less than 4 GB even with 64-bit base address registers, but since GCN supports at least 40-bit virtual address space, I guess it made sense to support the full range of sizes (up to 2^40=512 GiB).

Well, then it actually looks like 'Whoops, our driver code had a #define for a maximum BAR Size, and no-one bothered to review it since 2005!" rather than a exclusive feature specifically designed for RNDA2, so this will probably trickle down to GCN drivers quite soon.


There's really not a lot of overhead in flushing AMD's HDP cache on each command buffer submission
I'm not sure how they could get away with not flushing, because the driver can't know if the app wrote into a mapped portion of the BAR prior to the submission.
Flushing the cache and moving entire pages does incur an significant overhead, comparing to a directory-based coherence protocol over PCIe like CXL - but I guess the latter is unlikely now, considering AMD's description of Smart Access Memory.
 
Last edited:
This post wasn't intended to exist but it has come to this ...


Why even have explicit APIs like D3D12 or Vulkan in the first place if drivers are going to do emulation behind our backs ? This literally undermines the design principles of those APIs which were supposed to avoid expensive emulation and minimize driver maintenance as much as possible ...

Drivers having to do emulation was one of OpenGL's many biggest downfalls in case anyone were wondering why GL on AMD was slow but their case isn't just isolated to them as well ...


Would performance and driver maintenance be classified as 'arbitrary' reasons ? What would be the backup plan for AMD if they exposed a proprietary vendor extension in their public drivers which causes potential performance issues and developers started shipping software based on their availability ?


Here's a list of current changes for anyone interested so the cross vendor ray tracing extension obviously isn't a superset of the proprietary Nvidia extension. What's more is that ray queries aren't available with the Nvidia extension either which is necessary functionality to support inline raytracing so why would AMD support an extension that doesn't even expose their fast paths in their hardware/drivers just for a couple of titles ?

How is losing performance in double digit percentages supposed to be politically acceptable for AMD ?
 
What's more is that ray queries aren't available with the Nvidia extension either which is necessary functionality to support inline raytracing so why would AMD support an extension that doesn't even expose their fast paths in their hardware/drivers just for a couple of titles ?

Is it AMD’s position that inline is always faster on their hardware? According to Microsoft there’s a trade off and inline isn’t always the best option (e.g. due to higher register pressure or suboptimal scheduling).
 
How is losing performance in double digit percentages supposed to be politically acceptable for AMD ?

I don't see it as a win for AMD at all. If Ubisoft doesn't want to use standard APIs then support for their games, and any extra sales Ubi would garner, can fuck off.

There's a good bit more high end video game developers than there are GPU vendors, which is 2. AMD has the upper hand in the longer run and forcing devs to support native compatibility is perhaps neutral for them now and a definite win going into the future.
 
Is it AMD’s position that inline is always faster on their hardware? According to Microsoft there’s a trade off and inline isn’t always the best option (e.g. due to higher register pressure or suboptimal scheduling).

No but based on Dave Oldcorn's presentation, I fail to see how the shader binding table approach is ever better in their case. They explicitly state that inline ray tracing is the "ideal API" (I assume on their end) to implement these "common raytracing techniques" ...

If you're doing ray traced shadows they make it guarantee that you're getting the "best-in-class performance" and they see higher efficiency with ray traced reflections too. Dave mentions that ray traced ambient occlusion is also another common ray tracing technique that benefits from inline ray tracing and it's somewhat implied ray traced soft shadows are too. Combined compute passes is another powerful optimization to fuse the compute shading (denoising) with the ray shading on their hardware ...

If you look at their FuturisticCity rendering pipeline, only the inline form of ray tracing is used in the demo. There's also a combined ray traced soft shadowing and reflection ray shading pass calling TraceRayInline() twice. Going into more detail about that pass, I assume they trace rays for their soft shadows first and in one of Dave's other slides these soft shadows are then "cached for subsequent reuse" for their reflections so then they trace rays again from that very same shading pass to render the reflections. I see two optimization scenarios with inline ray tracing with AMD HW. The first is being able to combine the ray shading pass with denoising pass. The second being is caching soft shadows for reuse when rendering reflections ...
 
Here's a list of current changes for anyone interested so the cross vendor ray tracing extension obviously isn't a superset of the proprietary Nvidia extension. What's more is that ray queries aren't available with the Nvidia extension either which is necessary functionality to support inline raytracing so why would AMD support an extension that doesn't even expose their fast paths in their hardware/drivers just for a couple of titles ?
I don't think Intel would deliberately support an extension that does more harm than good, and apparently they have no problem with implementing Nvidia's extensions.

In a recent interview Intel stated that:
Intel plans to keep using Khronos' open-source ray tracing extensions as much as possible. However, they might look at implementing Nvidia's in-house extensions if they find more and more games using Nvidia compared to Khronos' open-source solution.
 
No but based on Dave Oldcorn's presentation, I fail to see how the shader binding table approach is ever better in their case. They explicitly state that inline ray tracing is the "ideal API" (I assume on their end) to implement these "common raytracing techniques" ...
Well then it's up to MS to release Ultimate Direct RayTrace DX12.x that will support inline RT. AMD follows the full DX Ultimate path that MS has laid out. It's Nvidia that is doing it's own thing.
 
So console games start as "DXR 1.1"? Won't run on Turing?...
Would depend on the new features Nvidia added to Ampere and what Turing supports and what MS defines in DXR1.1 and if Turing has the feature set. It most likely could, just the feature won't be as advanced as the Ampere version for obvious reasons.
 
Back
Top