AMD Ryzen 8000G to feature Zen 4(c) and RDNA3 architectures with the 8700G/8600G/8500G and 8300G SKUs

[leadeater]

21 minutes ago, hishnash said:

They could put the LPDDR on the organic interposer substrate (like apple) but still use a socket from the interposer to the motherboard.  

Doesn't actually have to be on package memory at all, it's more that system design wise having socketing as an option becomes largely pointless. Once you have a mainboard with a fixed memory capacity you may as well just pair a balanced and reasonable CPU with it and be done with it. That way the highest end APU could be deployed with 12 channels of memory, the next down 8 channels, then 4 channels etc and compute is nicely balanced with bandwidth and cost.

 

Other than scaling memory channels this is how laptops are done already, you do get LPDDR in standard laptops with Intel and AMD CPUs/APU but they are still only 2 channels.

 

The above realistically applies to having a socketed SoC and DRAM package, why, what benefit does it actually give realistically. Also that's just Intel Sapphire Rapids with HBM, which is the best way to do this but very costly as you can still have slower memory DIMMs for more capacity.

 

It's also in turn why ARM or x86 desktop system designs that are comparable to current ARM systems isn't doom and gloom because you can still have memory DIMMs even with on package memory etc.

[porina]

2 hours ago, WereCat said:

Would be interesting to see how X3D APU would perform if most of the extra L3 would be for the iGPU. Though I don't think it makes much sense for desktop but it may be a banger in handhelds.

It would require a significant design change though. On the chiplet based CPUs, the GPU would have to access the CPU cache over Infinity Fabric. Based on diagrams of Cezanne (Zen 3 APU) it is similar there, except the IF is internal to silicon. IF would choke bandwidth back down to ram levels, or become a power hog if they enhanced it. V-cache would instead have to connect to the GPU and at that point, is that the best option still? For instance, rather than a "small" cache would a bigger lump of other memory technology provide better perf or value? When Intel tried similar previously they implemented it as L4 so both CPU and GPU parts could use it.

 

2 hours ago, leadeater said:

You'd realistically have to go with LPDDR(X) and scale up the memory controller which basically means BGA systems not LGA socketed aka something people here do not want.

I've not looked at LPDDR very closely but it seems to offer its advantage mainly from running at higher speeds than competing conventional DDR of the time. While it is faster, IMO it isn't enough faster to make a game changer of a difference. I think we'd have to look at least at 2x DDR BW to get competitive with lower end gaming dGPUs.

 

Overall bus width was the same from memory. Widening it could help, but then you could say the same for DDR.

[WereCat]

11 minutes ago, porina said:

 V-cache would instead have to connect to the GPU and at that point, is that the best option still? For instance, rather than a "small" cache would a bigger lump of other memory technology provide better perf or value? When Intel tried similar previously they implemented it as L4 so both CPU and GPU parts could use it.

We already know it helps a lot on because of RDNA2 and RDNA3 dGPUs... Scaling though starts to fall off on higher resolutions.

[leadeater]

30 minutes ago, porina said:

I've not looked at LPDDR very closely but it seems to offer its advantage mainly from running at higher speeds than competing conventional DDR of the time. While it is faster, IMO it isn't enough faster to make a game changer of a difference. I think we'd have to look at least at 2x DDR BW to get competitive with lower end gaming dGPUs.

 

Overall bus width was the same from memory. Widening it could help, but then you could say the same for DDR.

The big advantage is DRAM die stacks in the package creating multiple memory channels per package which is how Apple gets very large bandwidth out of 2 LPDDR packages, The arrangement is just different between DDR and LPDDR in that regard but you could stack normal DDR but it's not done and also being higher heat might be a bit more of a problem 

 

400GB/s is plenty, if you want really high end then 48* LPDDR packages and 800GB/s. As with all things though, $$$.

[porina]

4 minutes ago, WereCat said:

We already know it helps a lot on because of RDNA2 and RDNA3 dGPUs... Scaling though starts to fall off on higher resolutions.

Cache accessible by the GPU would help, but my point was that as it is conventionally connected to the L3 of the CPU cores. The GPU would have to go through Infinity Fabric to access it which would negate any performance benefit. If the cache were directly connected to the GPU, it would not be so constrained. But then my thinking is, what is the cost of attaching V-cache? Is attaching another bigger but slower memory solution of similar cost going to give better end user benefits?

[WereCat]

14 minutes ago, porina said:

Cache accessible by the GPU would help, but my point was that as it is conventionally connected to the L3 of the CPU cores. The GPU would have to go through Infinity Fabric to access it which would negate any performance benefit. If the cache were directly connected to the GPU, it would not be so constrained. But then my thinking is, what is the cost of attaching V-cache? Is attaching another bigger but slower memory solution of similar cost going to give better end user benefits?

The cache on RDNA2 and 3 already goes trough infinity fabric and in case of RDNA2 you can even overclock it with external software. 

 

The stock IF on my 6800XT is 1940MHz and I can OC it to 2200MHz at the default 1150mV SOC... It doesn't really make much difference... At best 2% improvement in Time Spy. 

 

Edit:

 

I may be actually wrong here, not 100% sure but it may be the memory and not cache that goes trough IF. 

I still think it's the cache because VRAM OC yields fast higher benefits regardless if I OC or DC the FCLK. 

[porina]

56 minutes ago, WereCat said:

The cache on RDNA2 and 3 already goes trough infinity fabric and in case of RDNA2 you can even overclock it with external software. 

 

The stock IF on my 6800XT is 1940MHz and I can OC it to 2200MHz at the default 1150mV SOC... It doesn't really make much difference... At best 2% improvement in Time Spy. 

I have to admit I'm unfamiliar with the internals of RDNA. My talk of the IF was purely from a CPU perspective. At best when run synchronously, the bandwidth of IF matches that of the maximal ram configuration. It is clear the L3 controller is attached to the CPU cores, and the to go to the GPU would require a trip over IF. It is very possible the dGPUs are configured differently to allow for that.

[Doobeedoo]

Good to see new gen of APUs though. I'd like to see an 8 core X3D cache with way more GPU CUs with DRAM that would be amazing. I'm sure something like this would be amazing in a laptop. But also in a desktop for tiny PC.

[leadeater]

1 hour ago, WereCat said:

The cache on RDNA2 and 3 already goes trough infinity fabric and in case of RDNA2 you can even overclock it with external software. 

Talking about Infinity Fabric is not an easy thing, it is not a singular and unique technology name and implementation. It's a generic name AMD uses for it's connectivity buses which means the IF in the CPU between chiplets is not the same as the IF in dGPUs and not the same IF between dGPU (Radeon Instinct).

 

Quote

We also learn that the Infinity Links, the interconnect technology between the memory and GPU is operating at 9.2 Gbps. This is 10 times higher bandwidth density compared to Ryzen and EPYC IFOP (Infinity Fabric On-Package) approach. AMD further claims that the peak bandwidth between MCDs and GCDs is at 5.3 TB/s.

 

1 hour ago, WereCat said:

I may be actually wrong here, not 100% sure but it may be the memory and not cache that goes trough IF. 

I still think it's the cache because VRAM OC yields fast higher benefits regardless if I OC or DC the FCLK. 

Infinity Cache is in the MCD's, GPU L2 cache in is the GCD.

[Helpful Tech Witch]

7 hours ago, porina said:

Before Zen 4, Intel desktop iGPUs were far better than AMD desktop iGPUs since AMD didn't have any. For clarity, I'm comparing the full desktop CPUs, which would be the chiplet based ones, not APUs with cut down features.

 

Intel doesn't provide big iGPUs on desktop on the basis that anyone that cared about performance would get a dGPU. Similarly now that AMD have joined in on Zen 4, chiplet iGPUs are much smaller than APU iGPUs so they have the same strategy in that space. The only advantage AMD has is the offering of APUs which have comparatively bigger iGPUs at the cost of reduced CPU performance.

This is semantics and you know it. Im sorry that the amd apus dont live up to your definition, but they do have desktop igpus. Theyre desktop chips with just less performance.

[filpo]

New info cuz why not 

Summary: Loads of Mobo manufactures have rolled out new bioses to prepare for 8000G (or 7000G)

Asrock releasing one for ryzen 8000g six days ago however it was called 7000g (which may allude to a 7000g but I think they just changed the name to 8000G)

 

Quotes:

Quote

 

Quote

The latest driver was spotted at station drivers by HXL (@9550pro) and is part of the 5.11.02.217 release which is not yet listed over at AMD's official driver webpage. The official version is still the 5.08.02.027 release but the major update in the upcoming release is the "AMD PMF-8000 Series" driver package which confirms the Ryzen 8000 CPU family. The AMD PMF "Platform Management Framework" driver optimizes the overall performance and efficiency of the systems. This package gets updated to the newer 23.5.9.0 release which is much newer than the existing 23.2.3.0 release for Ryzen 7040 APUs.

 

 

Quote

The AMD AGESA 1.1.0.0 BIOS firmware is an extension to the AGESA 1.0.7.0, 1.0.8.0 & 1.0.9.0 BIOS patches which were made to address thermal limits and tune memory support. But another major feature of these BIOS releases was to add initial support for AMD's upcoming Ryzen 7000G Phoenix APUs which are expected to launch soon.

 

From what we had gathered, the current AGESA 1.0.8.0 and the 1.0.9.0 BIOS updates had the basic and initial support for Ryzen 7000G APUs and there was a lot of work still required. A motherboard vendor we talked to commented on the 1.0.8.0 and 1.0.9.0 BIOS releases as "Useless" when it came to Ryzen 7000G support and overall AM5 stability. But now, it looks like there's a new BIOS version available in the form of AGESA 1.1.0.0

Sources: Gigabyte confirms the launch of AMD's next-gen desktop APU (Ryzen 8000G) series scheduled is for the end of January - VideoCardz.com

AMD's Next-Gen Ryzen 8000 CPUs Spotted In Latest Driver Package (wccftech.com)

ASRock Rolls Out AMD AGESA 1.1.0.0 BIOS Firmware For X670E Taichi Motherboards (wccftech.com)

[Somerandomtechyboi]

Itll be interesting to see how the zen4c cores overclock and also to see how well it handles higher vsoc >1.3v incase it isnt the same as the cpus where they up and die >1.3v

 

Looking at cezzane and its absolutely busted fclk capabilies + imc (1:1 ddr4 5000+) ram oc would also be very interesting