AMD Launches Ryzen 5000 Mobile: Zen 3 and Cezanne for Notebooks
by Dr. Ian Cutress on January 12, 2021 11:52 AM ESTIt has been a year since AMD launched its previous generation Ryzen Mobile processors. At the time, the update from Zen to Zen 2, as well as moving to TSMC’s 7nm manufacturing process, gave the company the biggest boost in its notebook performance and battery life in AMD’s history. It’s difficult to reinvent the wheel again, but AMD is hoping that its new Ryzen 5000 Mobile processors build on the momentum that started last year. The new processor line-up has 13 new models, targeting the traditional U series and H series markets, as well as a couple of new areas AMD is looking to expand into.
AMD Ryzen 5000 Mobile:
8 Cores of Zen 3
8 Compute Units of Vega
For those familiar with the previous generation of Ryzen 4000 Mobile, then the situation for these new processors is relatively simple: replace the Zen 2 cores with Zen 3 cores, combine the L3 cache, double the L3 cache, and that’s about it.
For everyone else, what we have here is a single piece of silicon that contains one group of eight Zen 3 cores that share a single 16 MB non-inclusive L3 cache. AMD’s big marketing tool for the other Zen 3 families on the desktop is that the size of the L3 cache effectively reduces main memory latency and helps gaming performance, and so with the new mobile processor they’ve combined the two four-core complexes into a single eight-core complex, then doubled the amount of cache, enabling each processor to have access to all the cache on the CPU at the same time.
These cache updates work in line with core updates that the Zen 3 core microarchitecture provides. We’ve covered the Zen 3 microarchitecture in our desktop processor review, which you can read here. Just replace the L3 cache numbers with 16 MB to get a sense of what the mobile processors will have.
For graphics, there are no updates moving from Ryzen 4000 to Ryzen 5000, and we still have eight compute units of Vega-era design. This will be a bit of a frustration for a few users that may have been hoping for some RDNA2 level updates to push performance along, especially with the added efficiency and performance gains that an RDNA2 design should have possibly brought to the table. The simple matter here is that when AMD put Vega on its Ryzen 4000 Mobile in 7nm, the efficiency was increased enough that enabled sustained development and kept AMD on cadence for its next generation. We’re at a stage now where AMD might consider updating the CPU/GPU on its APUs in alternate years, if that keeps the rate of product releases in line with its other designs.
For additional connectivity, we expect the Ryzen 5000 Mobile processors to also keep the same as the previous generation: eight lanes of PCIe 3.0, support for NVMe and SATA, and DDR4-3200 / LPDDR4X-4266. Again, leveraging the previous generation design helps AMD’s generational time-to-market (something that AMD has been saying it needs to keep track to), but we do perhaps expect updates next time around.
While we don’t have a Ryzen 5000 Mobile silicon die on hand (something we lose by not having a physical CES event this year, but totally understandable), because the Zen 3 cores are slightly larger than the Zen 2 cores, overall the die size of Ryzen 5000 Mobile should be slightly bigger. This should not have much of an effect on designs, depending on how the packages arrange their pin-out design. Given the similarities, it is possible for the pin-out to be identical to the previous generation.
All of AMD’s Ryzen 5000 Mobile processors (3 exceptions, listed below) are binned from this one silicon die design.
Ryzen 5000 Mobile, H-Series: H, HS, and new HX
AMD’s top tier mobile parts are all in the H-series. Traditionally these processors are listed with a TDP of 45 W, however last year we saw AMD experimenting with a newer 35 W category called ‘HS’. This year AMD is again introducing a new level called ‘HX’ for its overclocking models, going above the standard H-series TDP.
AMD Ryzen 5000 Mobile: H-Series | |||||
AnandTech | Cores Threads |
Base Freq |
Boost Freq |
TDP | Zen |
Ryzen 9 5980HX | 8C / 16T | 3300 | 4800 | 45W+ | Zen3 |
Ryzen 9 5980HS | 8C / 16T | 3000 | 4800 | 35W | Zen3 |
Ryzen 9 5900HX | 8C / 16T | 3300 | 4600 | 45W+ | Zen3 |
Ryzen 9 5900HS | 8C / 16T | 3000 | 4600 | 35W | Zen3 |
Ryzen 7 5800H | 8C / 16T | 3200 | 4400 | 45W | Zen3 |
Ryzen 7 5800HS | 8C / 16T | 2800 | 4400 | 35W | Zen3 |
Ryzen 5 5600H | 6C / 12T | 3300 | 4200 | 45W | Zen3 |
Ryzen 5 5600HS | 6C / 12T | 3000 | 4200 | 35W | Zen3 |
These two series, HS and HX, represent different strategies for AMD. Last year when HS was introduced, AMD stated that these 35 W models were special, requiring system design approval from AMD in order to have access to them, as they enabled the same base and turbo frequencies but at a much better efficiency point. This year that distinction seems to have dropped away a bit, with the HS models now simply giving the same turbo but lower base frequency than the standard H. Note that the change in TDP, from 45 W to 35 W, in the various TDP modes, typically relates to changes in base frequency, so in that instance AMD is more aligned with what the market is used to.
For HX, this changes AMD’s offering. Overclockable models in laptops isn’t necessarily new (Intel has done it for years), but AMD has taken the detail to explain that the TDP is raised to a ‘45W+’ design for these parts. This allows the OEM partners to ultimately define their TDP level, and have the sustained base frequency increased match expectations for the hardware it is built for. This means that desktop-replacement devices can fully turbo up to 65 W (or higher?) as needed, rather than those OEMs having to reply on building a socketed platform in a portable chassis.
Users might also note that the Ryzen 9 processors here do not have traditional H series parts. Because the mobile market is always a bit odd in its numbering scheme, the Ryzen 7 5800H takes that role, because it still has eight cores. If OEMs want the Ryzen 9 branding, they either have to build something sleeker for a 35W HS, or something beefier for the 45W+ HX.
AMD is advertising the Ryzen 9 5980HS as the best processor for portable gaming performance, whereas the Ryzen 9 5980HX as the best mobile processor for gaming. AMD showcases the 35 W model as scoring 600+ in Cinebench R20, in line with the desktop Zen 3 processors launched last year.
Ryzen 5000 Mobile: U Series (not all Zen 3)
The U-series portfolio is where AMD’s processor cycle updates cause a bit of bother. In a normal product cycle, we expect everything to be upgraded from the older to the newer, however this time around AMD is mixing and matching the U-series 15 W products between Zen 2 and Zen 3. So while there are new Zen 3 hardware options at 15 W, some of these processors are simply re-badges of Ryzen 4000 Mobile instead.
AMD Ryzen 5000 Mobile: U-Series | |||||
AnandTech | Cores Threads |
Base Freq |
Boost Freq |
TDP | Zen |
Zen3 | |||||
Ryzen 7 5800U | 8C / 16T | 1900 | 4400 | 15W | Zen3 |
Ryzen 5 5600U | 6C / 12T | 2300 | 4200 | 15W | Zen3 |
Zen2 | |||||
Ryzen 7 5700U | 8C / 16T | 1800 | 4300 | 15W | Zen2 |
Ryzen 5 5500U | 6C / 12T | 2100 | 4000 | 15W | Zen2 |
Ryzen 3 5300U | 4C / 8T | 2600 | 3800 | 15W | Zen2 |
The top processor is the Ryzen 7 5800U, which is Zen 3, and there is also a Ryzen 5 5600U, which is also Zen 3. However, the others are Zen 2 based, using the same Renoir die as Ryzen 4000 Mobile.
Reasons for offering a re-badge can be confusing. Normally it is done to appease OEM partners that have a singular design and want to get the benefit of the latest generation nomenclature but not have the expense of developing a new unit. AMD’s public reasoning here has not been given, although in the past we’ve seen it beholden to its OEM partners (Carrizo and Carrizo-L) for this sort of co-design.
Despite this, AMD is promoting the Ryzen 7 5800U as its most efficient mobile processor to date, citing 21.4 hours battery life on a 53 Wh battery during 1080p video playback with Wi-Fi on, or 17.5 hours in MobileMark 2018’s battery life test. The footnotes state this was an AMD reference platform, though details on screen brightness were not given.
Overall, AMD is citing that they will have 150+ design wins this year for Ryzen 5000 Mobile, compared to 100+ for Ryzen 4000 Mobile. Availability for these systems, both the U-series and H-series, should start this February.
117 Comments
View All Comments
lmcd - Tuesday, January 12, 2021 - link
Vega is mediocre independent of its memory problems. The iGP on Tiger Lake easily outpaces Vega.Tams80 - Wednesday, January 13, 2021 - link
Xe as an iGPU is better (as you'd body well expect being newer), but it's not that much better.It's in a weird spot where while it is more powerful, that extra power isn't that useful
vladx - Tuesday, January 12, 2021 - link
Yes Intel Xe is better than Vega APU, from gaming to video decoding/encoding.Spunjji - Wednesday, January 13, 2021 - link
Xe on Tiger Lake is indeed faster than Vega 8 - though not as much as synthetic benchmarks might indicate, and with some exceptions due to driver bugs. It also has better video hardware.vlad42 - Tuesday, January 12, 2021 - link
And RDNA2 would have significatly helped to alleviate the memory bandwidth bottleneck thanks to the 128 MB Infinity Cache and using delte-E color space compression throughout the entire gpu (introduced with RDNA1). The delta-E compression update would allow more data to be stored on all sub-L2 caches. This would cause the gpu to have fewer cache misses and thus be more efficient with the system memory bandwidth it has. Vega, for comparison, only uses delta-E compression in the memory controllers and L2 cache.mczak - Tuesday, January 12, 2021 - link
There's no way a rdna2 based APU would have 128MB Infinity Cache - the cache alone takes up over 100mm² die space, which would be completely unacceptable for such an apu. You'd have to scale that back a lot (probably to 16MB or so) to be viable, and I'm not sure how much it would help at that point. (Maybe future AMD APUs will actually have shared cpu+gpu cache, intel does this since ages, ARM SoCs have such caches (called system level cache there) too, right now with how AMDs cpu L3 cache is organized that's not really possible, since the L3 is a victim cache to the cores within the CCX cluster, so it would need to be an additional cache level.)You are right though that rdna2 (and rdna1) should be more bandwidth efficient than vega, even without additional cache, due to the changes in how framebuffer compression is handled.
TheinsanegamerN - Tuesday, January 12, 2021 - link
Why not? Intel did a APU with broadwell, that had 128MB of cache, on 14nm, and it worked great. Even their cut down 64MB iris pro models had notable performance improvements.mczak - Tuesday, January 12, 2021 - link
The broadwell APUs were using a off-die L4 cache - this was using a separate 128MB edram die, built on a 22nm process, which measured "only" 77mm². Note you cannot integrate dram into the "standard" 7nm TSMC process, and rdna2 infinity cache is just ordinary sram integrated into the same silicon as the gpu itself, hence why it needs more die space even though it's using a much smaller manufacturing process.And this 7nm TSMC process is expensive, and availability is actually scarce, so 128MB is definitely not an option (unless AMD would try off-die cache as intel did, not sure how viable it would be nowadays).
Spunjji - Wednesday, January 13, 2021 - link
There's a reason Intel only did that once, and charged an absolute fortune for it when they did.vlad42 - Tuesday, January 12, 2021 - link
I agree that a 128 MB cache would not make sense at least until stacking is viable (5nm perhaps based on articles from this sight covering TSMC?). However, I think a 64 MB or 32MB cache might be reasonable. Picasso is 209.78 mm2 compared to Renoir which is 149.22 mm2. So, with 64 MB of cache, that could still make for a smaller chip than the 12nm Picasso depending on the die size increase with Cezanne. If that ends up being too big due to manufacturing and pricing constraints (AMD could always have a 2 APUs, one high cost and one low cost much like Intel does), then 32 MB should be doable as I imagine it would probably be pretty close to what the 3 CU difference between Picasso and Renoir would amount to - maybe the cache would be a little larger. I will admit, I have not been able to find out how big the 7nm Vega CUs are. That said, assuming I am interpenetrating the Big Navi die shot correctly, it looks like the size of 32MB of Infinity Cache is between the size of 3 and 4 of the RDNA2 CUs.As for benefits, the 32MB edram cache did wonders for the original Xbox One and that cache had far less bandwidth and no color space compression (so it would be effectively smaller). I have no idea how beneficial a 16MB cache would be but I doubt the scaling is linear - meaning I think it will provide worse than linear scaling at those capacities. However, relying solely on DDR5 is a bad idea. It looks like AMD, Intel, etc., will jump straight to the fastest JEDEC spec for DDR5 (6400) or very close to the fastest. While this will be a big boost to performance when it is first adopted, there will not be significant improvements again until DDR6, or whatever replaces DDR5. This will still limit the maximum bandwidth available to the iGPUs to roughly 64-72 GB/s when we take into account the bandwidth needed for the CPUs. This would puts the iGPU between the MX350 and MX450, old low end GPUs by that point, in terms of raw bandwidth and behind both once Nvidia's superior color space compression is considered - I have not heard of AMD increasing the amount of compression since Polaris, just expanding where the compression is used. This will be very limiting long term because it will be years before a replacement for DDR5 is available.
While it would be interesting if AMD were to use the CPU's L3 cache instead of a dedicated Infinity Cache, I doubt they would want the CPUs in APUs to have access to more L3 cache than the dedicated CPUs seen in the desktop Ryzen, Threadripper and Epyc chips. I also suspect that the L3 cache is optimized far more for latency over bandwidth, which would be to the detriment of the iGPU both from a bandwidth and capacity standpoint. I could see AMD introducing an L4 cache though. This could then be put on the IO die for the CPU only parts and avoid the problem of the high performing CPU only parts having access to less cache.