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

It will become a huge problem for RDNA, but it will take a while until Mesh Shaders and Sampler Feedback get fully used, I would assume so, as that needs significant changes to a game's code.

So for cross gen RDNA might be still fine and RDNA users paid less than for competing GPUs, I guess they already expected no longevity.

In regards to Raytracing, RDNA buyers clearly didn't care about Raytracing at all... the issue is, the GPU will care once Raytracing gets efficient enough to replace certain raster effects like Global Illumination as we see with RTXGI, and then it will lag significantly behind cards with DXR acceleration... if AMD cares about adding DXR support for RDNA that is. It's fair to assume that will happen sooner rather than later, using Raytracing significantly decreases time and cost in development and by the end of cross gen, there will be a huge install base of cards with DXR acceleration including the consoles plus for cards without DXR acceleration, it can still be emulated via software with decent enough performance. I mean yeah visual fidelity and performance would have to be significantly dialed back for cards without DXR acceleration, but the game would still run not excluding any users.. again, if AMD cares about adding DXR support to RDNA. If not, then in that case it's dead in the water.

Are you talking about DXR support without hw acceleration ? It will be slow as hell... Even witj all the optimisations in the world...
 
Last edited:
I don't know if it's a useful comparison to make, but mesh shaders is a similar kind of "specialised software" to replace "generic hardware".
Probably this comparison is not too usefull because mesh shaders were made to get rid of slow HW serialization points like primitives redistribution for workload balanching, IA, culling hardware, etc, etc.
Geometry processing can be mapped to compute shaders execution model and can be scaled efficiently with number of SIMD units, likely better then with traditional graphics pipeline (once we move to wider hardware).
On the other hand, divergent nature of tree traversal doesn't sound like a good candidate for SIMD processing.
 
I get a lot of vulkan/dx12 vibes from dxr. Devs want low level access. I wonder if devs had low level access would it just mean higher barrier of entry and even less games using ray tracing? Low level access sounds like great idea until one realises that means having to optimize each hw separately(ampere, turing, rdna2 and small chips vs. large chips). It becomes a nightmare. At this point black box might be better and believe the owner of black box does the right optimizations for your game.

In ideal world devs would have option to choose low level/high level api. I suspect we will get there eventually, just like with dx12/vulkan.

It’s like with any new feature the experts and uber developers will always demand more control. However for the average developer the off the shelf implementations are likely very useful and better than anything they would come up with on their own. It’s better to start with something approachable and functional that actually makes it into games.
 
It will be slow, but it will still work.

RTXGI supports any DXR capable card, even a 1060 and according to some tests, it runs pretty well.
We did re-test the 1080Ti as a reference point for the fastest non-RT card. In most current raytracing titles, it is very slow with DXR on. For this very reason I guess AMD sees no merit enabling software-RT for it's RDNA or Vega cards.
 
Are you saying that there is stock and he’s lying?

I'm saying he has been caught in the past misquoting or outright lying about his "sources."
He is a glorified custom PC builder with a youtube channel that has enough of a following he has managed to wrangled into becoming a "benchmarking/review" channel with little to no actual technical knowledge on the industry other than being an "enthusiast" for a long time.
I have voiced the same criticism about Kyle, aka Bitwit, as well.

What I will say, is that most people criticizing AMD about the custom AIB cards are looking at this, seemingly, with blinders on comparing it to Nvidia's launch.
The situation, globally, is literally changing week by week. Could AMD have said, "We will be trying to launch at XX date but due to constantly shifting logistical challenges across multiple regions and markets, AMD and our Partners cannot guarantee anything."
Sure, but that would have gone over even worse with most people, especially shareholders/investors.

Remember, covid is over now. Countries aren't shutting down. The markets are only going up.

Edit- And I will point out that the reference card situation is going exactly as I had said. There are constant shipments every couple of days, at least from what I have seen in NA.
 
We did re-test the 1080Ti as a reference point for the fastest non-RT card. In most current raytracing titles, it is very slow with DXR on. For this very reason I guess AMD sees no merit enabling software-RT for it's RDNA or Vega cards.
That's because most RT settings in current titles are overkill, as demonstrated by Watch Dogs Legion. Even PCs medium setting is beyond what the consoles do, now imagine a PC low setting. I bet even a 1080Ti would have acceptable performance. I mean yeah the FPS drops would still be big, but you'd still have a playable experience.
 
I get a lot of vulkan/dx12 vibes from dxr. Devs want low level access. I wonder if devs had low level access would it just mean higher barrier of entry and even less games using ray tracing? Low level access sounds like great idea until one realises that means having to optimize each hw separately(ampere, turing, rdna2 and small chips vs. large chips). It becomes a nightmare. At this point black box might be better and believe the owner of black box does the right optimizations for your game.

In ideal world devs would have option to choose low level/high level api. I suspect we will get there eventually, just like with dx12/vulkan.

Would it be possible to train an AI to do the optimizations? that would really change the game. no pun intended lol.
 
1606322223132-png.999702

https://www.proshop.de/AMD-Radeon-RX-6000-Series-overview
 
I'm saying he has been caught in the past misquoting or outright lying about his "sources."
He is a glorified custom PC builder with a youtube channel that has enough of a following he has managed to wrangled into becoming a "benchmarking/review" channel with little to no actual technical knowledge on the industry other than being an "enthusiast" for a long time.
I have voiced the same criticism about Kyle, aka Bitwit, as well.

What I will say, is that most people criticizing AMD about the custom AIB cards are looking at this, seemingly, with blinders on comparing it to Nvidia's launch.
The situation, globally, is literally changing week by week. Could AMD have said, "We will be trying to launch at XX date but due to constantly shifting logistical challenges across multiple regions and markets, AMD and our Partners cannot guarantee anything."
Sure, but that would have gone over even worse with most people, especially shareholders/investors.

Remember, covid is over now. Countries aren't shutting down. The markets are only going up.

Edit- And I will point out that the reference card situation is going exactly as I had said. There are constant shipments every couple of days, at least from what I have seen in NA.

I think the issue is AMD coming out and stating they had more stock than nvidia did and they put guide lines for stores to follow in how to sell them. We also had that AMD guy bet money that it would be better than nvidia's launch.

AMD might have given 3 or 4 times the amount of cards as nvidia to stores but they still sold out in seconds and amd has gone radio silent. since then. Now the stores control the conversation. If you notice they are all saying we got 0 aib stock or very little.

It was a badly handled launch with bad expectations. If they came out and said hey we are launching all the stock we have but its going to be very hard to get I think things would have gone better for them.


I also don't care for Jay's persona online (don't know him personally)
 
At $770, the Sapphire Nitro+ also goes up against custom-design RTX 3080 cards like the EVGA FTW3 and the MSI Gaming X. Now of course, none of those graphics cards are in stock, and people are paying insane prices to jump on the RDNA2 or Ampere train, so I'm sure Sapphire will sell everything they have, even at that price point. No doubt, RX 6800 XT and RTX 3080 are fantastic cards that will give you an amazing gaming experience, but there's only so much that can be worth. I heard from several board partners that their margins are really thin, because AMD is charging so much money for their new GPU, guess while stock is low we're going to have to pay for that.
Sapphire Radeon RX 6800 XT Nitro+ Review | TechPowerUp
 
Anyone, yes, but not too many. Numbers are if possible even worse than 3080 launch.

Wouldn’t be surprised if that’s true given relative market share and Nvidia’s likely larger global distribution channel. Whatever numbers Nvidia prepared for launch were likely much higher than AMD’s.

Nothing surprising here except that Azor guy on twitter giving people false hope that Radeon would succeed where GeForce, Zen, PlayStation and Xbox didn’t. I was able to snag a 5950x though and there are some good sales on b550 boards for Black Friday so all isn’t lost.
 
I don't know if it's a useful comparison to make, but mesh shaders is a similar kind of "specialised software" to replace "generic hardware".

It's hard to beat the hardware if you're only "replicating" what the hardware does already. The reason to use mesh shaders is that you want to do something that the hardware can't do directly.
It's at least in part trying to assimilate a fair number of other specialized software methods as well in the form of vertex, geometry, and tessellation shaders. Getting around the serialization of reading from the index buffer would be one fixed-function path replaced, although I'm not sure that on its own would be considered inherent to the hardware concept rather than a result of history. If Turing is used as an example, there were specific cases where the traditional pipeline could still win, like some tessellation scenarios. The continued evolution of the fixed-function pipeline also meant that the mesh shaders could frequently neglect certain things like the full suite of per-primitive culling options if the hardware could cull them easily. Part of the challenge would be weighing a fully-featured replacement shader versus the additional cost each programmable option incurs on the generic execution loop.

Yuri O'Donnell appears to be complaining that an "opaque" BVH, which the developer cannot manipulate directly, is a serious problem all on its own. This data format is the core of the ray accelerator hardware, and so using something like "custom inline traversal" is doomed, because the hardware that accelerates use of the opaque BVH is the most serious bottleneck. You can't help that hardware with its data, because the BVH is inaccessible.
The BVH structure would likely be a black box until there's more standardization. There's not a firm consensus on what the BVH should look like at a lower level, and it's often tuned to the packing and access requirements of specific architectures. I wouldn't relish the prospect of having to write a new BVH node format or heuristic for every cache subsystem that exists or could exist.
Part of winnowing down the possibilities would come from the hard data from deployed RT hardware, but without the acceleration that we have the data would not be forthcoming.

However, is it certain that the most serious bottleneck for ray tracing is the acceleration hardware for the BVH? The most performant solution so far is the one with more dedicated hardware.
Is it a clear win to have a generic software solution running on shader hardware. The AMD execution loop is partially programmable, and as such has a round-trip between the texturing domain, 32-wide granularity, LDS capacity and bandwidth contention, LDS latency, and a pointer-chasing workload on a long-latency memory critical path.
Making more of the process programmable means adding more dependence on things like the SIMD hardware, LDS contention, and more trips through the memory pipeline.
It may not be guaranteed that a more clever solution can get out from under greater fixed costs.
 
Back
Top