The Performance Uplift of RDNA 3 over RDNA 2...

Yes, this is an RDNA 2 card, I wasn't able to create a new one with RDNA 3 just yet...

Much was made about the performance uplift (or lack thereof) of the initial RDNA3 cards released by AMD. Navi 31 (the RX 7900 XTX and XT) failed to meet expectations - seemingly both internal to AMD and externally (for various reasons) - this lack of performance also extended to the RX 7900 GRE which, despite lower core clocks, still underperformed compared to where it could be calculated that it should be...

Disappointingly, Navi 33 (the RX 7600) performed exactly the same as the equivalent RDNA2 counterpart, the RX 6650 XT, showing that there was zero performance uplift gen-on-gen in that lower tier part...

In the meantime, rumours swirled that Navi 32 was going to be 'fixed'. So, what is the truth of the matter? I intend to investigate a little and get to the bottom of the situation like I did with my Ampere vs Ada Lovelace performance uplift analysis...

Ours is not to reason why...

Much like the RTX 4070 VS 3070 comparison, there is a large overlap in "equivalent" hardware features between the RX 7800 XT and RX 6800.

The on-die cache structure is a bit different, with L0 and L1 doubling in size, and L2 remaining the same. L3 cache is decreased in size from 96 MB on the RX 6800 to 64 MB on the RX 7800 XT, with the caveat that it is also a chiplet design so the cache is not located on the primary die - which increases latency of access and worsens data locality...

Last time, I theorised that the dual striped memory configuration - with the L3 cache split across multiple chiplets feeding from multiple separate accesses to the on-board memory chips would lead to  inefficiences and this appears to be confirmed in my testing on the product, with increased latency  occurring before the cache size is reached (seen below around 48 MB). The decreased locality and increased management overhead of the data leads to delays in delivery or access to that data. Meanwhile, the RX 6800 with the on-die L3 only begins to increase latency of access once the cache buffer is exceeded.

I experienced some issues with data testing into the GDDR memory access, not sure why. However, we can see the improved latency for the 7800 XT within on-die cache... (From Nemez's GPUPerfTest tool)

Other than that, all other elements are similar from being physically present in the device - RAM, number of compute units, etc.

What has changed in a more significant manner is the dual-issue design in the compute units and the uncoupling of the front-end operating frequency from the compute portion of the die.

These changes mean that, potentially, there's better throughput of instructions through the compute units in particular scenarios but also that while those compute portions of the die operate at around 2.4 GHz, the front-end operates towards 3 GHz - cutting down on latency of issuing those instructions.

As outlined in the introduction, we haven't seen either of these innovations provide much uplift in the products prior to those based on Navi 32, so lets see if that's still the case with this silicon...

Setting Up...

The base of my test system is as my recent Alan Wake 2 technical analysis:

• Intel i5-12400
• Gigabyte B760 Gaming X AX
• Corsair Vengeance DDR5 2x16 GB 6400
• Sapphite Pulse RX 7800 XT
• XFX Speedster SWFT 319 RX 6800

However, special considerations are given to the two GPUs, here. In order to level the playing field as much as possible, I've used the Adrenaline software to corral the core clocks of each GPU to be as close as possible to 2050 MHz. Unfortunately, the user ability to take control of modern Radeon GPUs is nowhere near as easy or precise as it is for Geforce cards, which means that I have not found a way to lock to a specific frequency - only control within ± 50 MHz. These small fluctuations should not really affect the outcome of this analysis but I wanted to make the note upfront.

Memory is another problem - AMD have the frequency of the memory so locked down that the user cannot force the memory below or above spec without the card placing itself into a safemode (circa 500 MHz core clock lock). This essentially means that the closest I could match the memory between the two cards was with an overclock on the RX 6800 to 17.2 Gbps and keep the RX 7800 XT at 19.5 Gbps (stock).

Both cards increase slightly but the RX 7800 was unable to be clocked high enough to reach a plateau...

With this information in hand, I took a quick look at the effect of memory scaling on the two cards. With the synthetic benchmark, Unigine's Superposition, I saw that both cards had a slight increase in performance with increasing memory frequency. 

The 6800 plateaued-off after a 100MHz increase, but I wasn't able to push the memory on the 7800 XT much further, either, as it quickly became unstable. 

Thinking it might be a power-related limitation, I re-performed the test with the maximum power limit to the board. The GPU core, itself, was positively affected by this change - showing that the 7800 XT is power-starved, but the performance due to memory scaling did not really improve (though it became more linear).

This implies that both cards are working near their optimum memory frequency,  as-is.

Memory speed really has no effect on application performance for the RX 7800 XT...

Translating that into a "real" application, in the form of my old standby, Metro Exodus Enhanced Edition, showed zero performance increase as memory frequency was lifted. In fact, due to errors introduced at the higher frequencies the RX 7800 XT's performance started to drop off.

I didn't import the graph here but the RX 6800 saw no drop in performance - it was just flat at all memory frequencies...

Much ado about something...

Moving on, I looked at the performance of the two cards in several gaming applications, limited as mentioned above.

In the less demanding games, I tested at 1440p - moving to 1080p for the more demanding. However, really and truly, a current generation €600 card should be able to play modern games at native 1440p. We'll see that isn't always the case, which is a shame...

Returnal and Spider-man typically show low gains on the order of 6 - 9 %. However, ray-tracing for Returnal has a 15 % increase in 'iso-clock' testing. Both games are considered relatively light on hardware so these increases, while real, are small in raw fps benefit.

On the other hand, Cyberpunk and Hogwarts Legacy, traditionally graphically heavy games to run, show typically consistent gains above 10 %, with only the broomflight test dipping below that. This is most likely due to a system I/O bottleneck as areas are loaded into memory as the view distance is very much increased by comparison - I find this test more demanding than the typical Hogsmeade test and can see shadows- and LOD pop-in on distant geometry.

Cyberpunk, especially,  seems to enjoy running on the RDNA3 architecture with around a 20 % performance increase over RDNA2 - something not shown before when testing the RX 7600.

Next, we come up against titles which are more strenuous for hardware to run, but not necessarily super performant, either.

Starfield sees another 20 % increase*, likely to do with some of the reasons outlined by Chips and Cheese regarding RDNA2's bottlenecks.

*This was performed before the current beta update...

Alan Wake 2 also shows a good 15 % increase between the two architectures. 

Finally, Metro Exodus sees an above 10 % improvement, with increasing performance as the difficulty of running the game gets harder at higher settings. This potentially indicates that with heavier workloads, the gap widens between the two architectures when given the same resources.

Superposition doesn't show as big of a gap here but that does make sense, given that we've already shown that it improves with memory frequency and my RDNA2 part is overclocked to narrow the gap...

One last thing to note. In these iso-clock comparisons, the RX 6800 is consuming around 140 W whereas the RX 7800 XT consumes around 170 W (under-reported by the AMD cards). Yes, you're getting more performance but there is an energy cost associated with that performance! Unfortunately, the increase in power usage is generally higher than the actual performance increase...

It's been pointed out to me that I was misunderstanding the power references in HWinfo, so I'm just putting this conclusion on hold until I can be more certain about what the data is actually saying. I will update here when I do!

Rationalising the product stack...

When set at the same core frequency, there's a generational difference in performance that varies, depending on the workload. When averaged accross all the tests, we're looking at a real-world architectural uplift of ~15 % for Navi 32 vs 22 silicon from my own data.

*Minus Superposition, as I believe that the memory scaling is not typical in real world applications.

If I take a look at the TechPowerUp review data, I find that RDNA 2 performance scaling has a logical progression (taking into account clock speed and compute unit count): we see the expected reduction in ability to make the most out of increased compute resources. On the other hand, RDNA 3 oscillates up and down in performance as it scales in compute resources. At face value, this appears confusing but I think it actually has roots in what I posited last time, and alluded to at the beginning of this article.

Per compute unit scaling is all over the place for RDNA 3...

As a result of moving the L3 "infinity" cache off-die onto the chiplets, there is a large hit to performance each time one of those chiplets is removed. So, the act of removing the bandwidth granted by otherwise having that chiplet results in below expected performance. There will also be lower data locality in the L3, further increasing latency to access data by having to jump out to the VRAM more frequently - and apparently, the data is implying that there isn't always a high enough hitrate on two of those products in the RDNA 3 stack relative to their compute demands. Hence why the RX 7700 XT and RX 7900 XT have worse performance scaling compared to their compute resources than the "full" chip RX 7800 XT and RX 7900 XTX.

With that in mind, we can apply the same logic to the already released parts to understand where, in terms of performance, they should be landing if they also experienced the same level of uplift as the RDNA 2 architecture:

The main take-away here is that RDNA3 is severely constrained by the L3 cache access at the higher end and by the lack of increased L0 and L1 front-end clock at the low-end...

The RX 7900 XTX and RX 7800 XT both show a good performance uplift per CU versus their RDNA 2 "counterparts" (18% and 21% respectively). Meanwhile, the RX 7700 XT falls short - with an RDNA 2 equivalent slightly beating the 7700 XT by 3%. The RX 7900 XT does still beat its 'equivalent' part but only by 6%.

At the lower end of the stack, the RX 7600 is nowhere near meeting any sort of generational performance uplift (as we already know) and since this part has the dual-issue improvement, and L0, and L1 cache size increases*, this cannot only be due to data locality as well. This also implies that the generational performance uplift I'm observing in the RX 7800 XT is mostly due to the front-end clock increase and not the dual-issue FP32 compute units. But let's have another look at the architectural differences, using Nemez's microbenchmarking tool to look at specific instructions running on the two different architectures:

*Incidentally, I've found some glaring errors in the information provided on TechPowerUp's GPU database. It appears that they have erroneously indicated that the L0 and L1 caches were not increased on the N32 and N33 products. However, looking into Chips and Cheese's benchmarking, (and my own testing for N32) it seems clear from the results that the cache sizes are indeed matching N31's. It is only the L2 and L3 caches which are reduced in size for each Navi die and via the infinity cache/memory interface...

For these tests, I'm once again keeping the core clocks locked at 2040 - 2060 MHz on the RX 6800 and keeping the core clock 'mostly locked' between 2000 - 2060 MHz on the RX 7800 XT - AMD's software just doesn't control it that well!

Straight away, the improvement to the FP32 pipeline is immediately obvious in almost all instruction types - though some have a greater improvement than others. What is interesting to me is the Int 16 improvement in RDNA 3 which I have not seen mentioned anywhere. An additional curiosity is the lack of gains in FP64 (not that it's really that useful for gaming?) given that I've seen it said that the dual-issue FP32 can run as an FP64 instruction as long as the driver is able to identify it. So, maybe this is purely the way this programme is written.

Elsewhere, the RDNA 2 card matches the performance quite well and even beats the RDNA 3 card in some instruction throughput - but these are generally not useful for gaming workloads.

Moving over to looking at the available bandwidth, we again see how the RX 7800 XT outperforms the RX 6800 - storming ahead between 20 KiB and 2 MiB, and 12 to 64 MiB sizes. The RDNA 3 part clearly has a big advantage even at "iso"-core clocks. However, once you have the clock frequencies cranked up to stock (or higher) there's just no competition between the two cards - the RX 7800 XT matches or outperforms the RX 6800 in every metric except for Int 64, which really isn't relevant to gaming.

Comparison between RDNA 2 and 3 bandwidths per data size at the same core (shader) clocks...

Speaking of operating frequencies, we see an interesting behaviour in the RDNA 3 part - at lower core (shader) clocks, the front-end is essentially equal. Whereas, as the shader frequency increases, the front-end frequency moves further ahead so that, by the time the shader clock is around 2050 MHz, the front-end is ~2300 MHz. Additionally, though I've not shown it below, at stock, the front-end reaches ~2800 MHz when the shader clock is ~2400 MHz.

This seems like a power-saving feature to my eyes - and it's not necessary to raise the front-end clock when the workload is light or non-existant!. There's no benefit!

The core clocks for the RX 6800 and the core vs front-end frequencies for the RX 7800 XT in Metro Exodus...

What's interesting here, is that Chips and Cheese documented that the cards based on N31 also use this same trick whereas the N33-based RX 7600 actually clocked the front-end consistently lower than the shader clock, whilst also having lower latency than the N22 (RDNA 2) cards it was succeeding. Implying that there's some architectural improvement in how the caches are linked.

All of this information is then quite confusing when taken as a whole. For the higher-end parts, it seems that bandwidth is vitally important to the L3 cache in order to operate efficiently, along with L3 cache size. It also appears that the increased front-end clock frequencies help a lot. I think that increasing the size of the L0 and L1 caches should help with data locality which should help with instruction throughput and specifically with improving the use of the dual-issue FP32 capabilities of the re-worked compute units. 

However, looking at the performance of N33, we see that the increase in L0 and L1 caches has had no apparent performance increase, that the card is data-starved due to the small L3 cache and that the lack of front-end core clock increase is also hamstringing the card compared to N23.

All of these design choices negate some amount of potential performance gains through the large latency and energy penalty for more frequently accessing not only the chiplets but further out to VRAM.

Conclusion...

In this very empirical overview, it is clear that, ignoring the increase in core (shader) frequencies, the RX 7800 XT has an architectural performance increase over the RX 6800. This also extends to the full N31 product (7900 XTX) as well. However, AMD's choice in reducing the L3 cache sizes for Navi 31 and Navi 32 appears to significantly hinder their overall performance. Additionally, the choice to move that L3 cache onto chiplets has resulted in a significant increase in energy use, and an over-dependence on the bandwidth to those chiplets. It also appears to be the case that there is an overhead for fully utilising the L3 cache, with performance dropping even before that limit is reached.

I didn't mention it in this blogpost, but the RX 7600 also doesn't have N31 and N32's increased vector register file size (192 KB vs 128 KB). However, since I don't have an understanding of how I could measure the effect of this on performance, I have decided to gloss over it - especially since Chips and Cheese do not appear to be overly concerned about it affecting N33's performance due to its lower CU count and on-die L3 cache.

What does appear to affect performance negatively is the choice to not clock the front-end higher on N33 and this is likely the source of a good amount of the observed performance bonus between the RDNA 2 and 3.

So, where does this leave us?

From my point of view, it appears that AMD made some smart choices for RDNA 3's architectural design which are then heavily negated by the inflexibility caused by going with the chiplet design and the need to bin/segregate in order to make a full product stack. 

Moving to chiplets has also had the knock-on effect of increasing power draw (and likely heat), which has a negative impact on the ideal operating frequencies that each design can work at which has hindered the performance of the card. Just looking back at Metro Exodus, increasing the stock settings on the RX 7800 XT to +15 % power limit increases performance by 4 % (though this is only 3 fps!) showing that the card is still power limited as-released and may potentially see a bigger benefit to reducing operating voltage than RDNA 2 cards did.

Additionally, the RX 7600 appears hamstrung by the lack of increased front-end clock - perhaps due to power considerations? - and it is the choice to decouple front-end and shader clocks that seems to me to be the biggest contributor of RDNA 3's architectural uplift as it is this aspect which appears to allow the other architectural improvements to low-level caches and FP32 throughput to really shine.