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

If I actually had a desktop computer to put it into, I'd definitely take you up on that!

 

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.

 

Still a nice GPU, AMDs have aged very well, in special compared to NVs products from the same age.

 

Looks like AMD has their Vulkan extensions worked out, assuming Khronos doesn't ship before Cyberpunk regardless (who is slower contest go!)

 

Vulkan? I thought Cyberpunk 2077 for PC is DX12 (DXR) only

PCGH - Cyberpunk 2077: The tech interview - "ray tracing proved to be quite a challenge"

Also, there are no AMD specific vulkan RT extensions. There is only standardized one - VK_KHR_ray_tracing (KHRonos) and NV specific one - VK_NV_ray_tracing

 

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

https://www.igorslab.de/en/amd-rade...ar-mode-turbo-mode-and-silent-mode-exclusive/

 

Looks like Cyberpunk is cleared.

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

 

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.

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.

 

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 ?

 

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).

 

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.

 

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 ...

 

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:

 

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?...

 

I mean they did. It's called DXR Tier 1.1

 

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.

 

If it supports DXR 1.0 then I don't see why It wouldn't support DXR 1.1

 

Because of all the things making it a 0.1 update?