Ryzen: Strictly technical

[Ajay]

There's a limited number of pins on AM4. Future products will likely have the same integrated I/O capabilities. Eight cores on AM4 (what is really a mainstream platform) I think is plenty for the next several years. All AMD needs to do is commit to IPC increases while maintaining the same or less power. Any clock improvements would only be a bonus. That seems to be AMD's forward focus is IPC improvements.

Wouldn't it make sense for AMD to modify the CCXs @ 7nm to,say, 6 cores each?
It would certainly be a large boost for their sever line (+50% on cores alone).

 

[itsmydamnation]

Wouldn't it make sense for AMD to modify the CCXs @ 7nm to,say, 6 cores each?
It would certainly be a large boost for their sever line (+50% on cores alone).

Yes it does,

Also by increasing the CCX size, cache coherency and memory inter connect complexity stays the same. CCX's keep track of their own L1/L2's. Memory controllers/cache directory keep track of what memory is currently in each CCX.

It also looks like intel will bring 6 cores to laptop ranges as well, so amd will want to "keep up" there as well.

 

[Ajay]

Yes it does,

Also by increasing the CCX size, cache coherency and memory inter connect complexity stays the same. CCX's keep track of their own L1/L2's. Memory controllers/cache directory keep track of what memory is currently in each CCX.

It also looks like intel will bring 6 cores to laptop ranges as well, so amd will want to "keep up" there as well.

Yes, because then the 7nm follow on APU can have 'up to' six cores with just one CCX - perfect, IMHO. We'll just have to wait and see.

 

[.vodka]

Software Optimization Guide for AMD Family 17h Processors

https://support.amd.com/TechDocs/55723_SOG_Fam_17h_Processors_3.00.pdf

 

[CrazyElf]

6 cores per CCX? So does that mean the follow on has 12 cores?

Then 24 for Threadripper 2 and 48 for Epyc 2?


I am wondering too about the clockspeeds on 7nm:
https://www.globalfoundries.com/sites/default/files/product-briefs/7lp-product-brief.pdf

Considering the source is Global Foundries itself, and they are the ones claiming 5 GHz.

 

[Jan Olšan]

The embedded roadmap was showing 4C/8T 7nm APUs. That could in theory mean that CCX has remained quadcore and the Starship chip is 3xCCX.

 

[moinmoin]

The embedded roadmap was showing 4C/8T 7nm APUs. That could in theory mean that CCX has remained quadcore and the Starship chip is 3xCCX.

Or CCX remains quadcore, the die remains 2xCCX and Starship consists of 6 dies.

 

[Jan Olšan]

I don't expect that. That would raise the number of "virtual sockets" from 8 to 12, if you used 2S motherboard. Which isn't trivial, if you look at past Opterons, then the first MCM generation (2-die) and now Naples (4-die), the maximum number of chips possible in a single system has always stayed the same - eight, or equivalent of 8S platform back when they used single-chips. With 2-die (Magny Cours), they had to cut number of sockets to 4S, now Naples (4-die) only offers 2S.

From that it is clear that raising the number of chips would be a problem. They would need to redo their logic so that each MCM is "virtually" just one socket again and not 4 like it is now.

 

[maddie]

Isn't the benefits of fabbing tiny die on 7nm late 2018 greater than increasing core #? From what we see, there are many more masking operations needed for 7nm than 14nm, at least before EUV is used. One would imagine defect management will be an issue. I think the greatest possibility is staying with a 4 core enhanced IPC CCX and pushing the clocks.

A ~ (100-110)mm^2 Zen2 8 core @ 4.5-5.0+ GHz would be a very attractive product.

 

[moinmoin]

I don't expect that. That would raise the number of "virtual sockets" from 8 to 12, if you used 2S motherboard. Which isn't trivial, if you look at past Opterons, then the first MCM generation (2-die) and now Naples (4-die), the maximum number of chips possible in a single system has always stayed the same - eight, or equivalent of 8S platform back when they used single-chips. With 2-die (Magny Cours), they had to cut number of sockets to 4S, now Naples (4-die) only offers 2S.

From that it is clear that raising the number of chips would be a problem. They would need to redo their logic so that each MCM is "virtually" just one socket again and not 4 like it is now.

All good points. But going by the roadmap you linked AMD will have separate dies for 1x dualcore CCX and 1x quadcore CCX at the low end and for use in APUs as well as 2x quadcore CCX and as you wrote 3x quadcore CCX. Considering how well AMD does off a single die atm I'm not so sure adding more dies to the portfolio is a big priority versus improving IF/MCM scalability.

 

[Jan Olšan]

Existence of the dualcore is contrary to the "they will want everything to have the same CCX", that is true. But that said, having to develop a 6core, 4core AND 2core CCX is bigger pita/expense than 2core and 4core.

 

[mtcn77]

While true that 40% clock speed uplift would entail 3.5>4.5GHz Ryzen 7's, I think the true benefit is again from the process scalability in bringing forth 24-core Rippers at the same power envelope as current Ryzen's.

 

[Jan Olšan]

Does anybody know the status of the Zen bug that leads to segfaults in GCC compilations under Linux?
I saw a claim that it is going to be fixed by microcode update, but with no source to base the claim on.

Finally, AMD shareholders that were concerned about previous reports of problems with Ryzen chip performance on Linux systems can breathe a sigh of relief. The firm now reports those issues have seemingly been fixed via a microcode update.

https://www.benzinga.com/analyst-ra...ip-dynamics-may-favor-advanced-micro-devices-

 

[DrMrLordX]

No idea, thought that kind of a bug is probably tracked in someone's database.

 

[moinmoin]

Does anybody know the status of the Zen bug that leads to segfaults in GCC compilations under Linux?

The two main threads on that very topic are still active with people reporting the issue and trying to track down the cause:
https://forums.gentoo.org/viewtopic-t-1061546-start-200-postdays-0-postorder-asc-highlight-.html
https://community.amd.com/thread/215773?start=120&tstart=0

 

[Dresdenboy]

The two main threads on that very topic are still active with people reporting the issue and trying to track down the cause:
https://forums.gentoo.org/viewtopic-t-1061546-start-200-postdays-0-postorder-asc-highlight-.html
https://community.amd.com/thread/215773?start=120&tstart=0

That last posting by benbennett in AMD's forum is interesting. 46h (and counting) no crash with using a low latency kernel.

 

[KTE]

Buildzoid (Actually Hardcore Overclocking) reviews the VRM on the MSI B350M Gaming Pro (cheapest B350 motherboard):
https://youtu.be/3BYAdyO9nZo

TLDW: The board is 3+2 and at realistic maximum ratings (125C, 100A, 1.42V vcore) the board will be dissipating 22W of heat through the vcore VRMs. He is pretty critical of the FETs used by MSI (which are the same PK616BA and PK632BA FETs on all their AM4 boards) because they are 1) cheap and 2) inefficient. Which is actually okay IMO on a $69.99 motherboard (price has dropped since I purchased).

BTW I wasn't able to set vcore voltage higher than 1.40V on any EFI for this board, so MSI clearly knows the board's limits and added an extra margin for safety.

MSI has always got away with close to maximum possible on the VRMs. Whatever they allow is usually clean but pushing limits that bum out pretty quickly.

Same since the Phenom.

Sent from my HTC 10 using Tapatalk

 

[BradC]

Does anybody know the status of the Zen bug that leads to segfaults in GCC compilations under Linux?
I saw a claim that it is going to be fixed by microcode update, but with no source to base the claim on.

This just keeps dragging on. Easy to reproduce fault, radio silence from AMD. I just want to swap my old FX-8350 for an 1800X, but I keep bumping into this rotten segfault.

 

[moinmoin]

This just keeps dragging on. Easy to reproduce fault, radio silence from AMD. I just want to swap my old FX-8350 for an 1800X, but I keep bumping into this rotten segfault.

"Easy to reproduce" is kind of wrong, people are still playing hit the pot trying to reduce the test cases to the actual cause. The best effort so far appears to be this script:
https://github.com/hayamdk/ryzen_segv_test
But it appears to run fine using GCC 7.0.1 instead the currently common GCC 6.3.0 (and haven't seen any tests with the most recent GCC 6.4.0 yet). Also there are some indications that error rate improved with AGESA 1.0.0.6a.

 

[french toast]

Isn't the benefits of fabbing tiny die on 7nm late 2018 greater than increasing core #? From what we see, there are many more masking operations needed for 7nm than 14nm, at least before EUV is used. One would imagine defect management will be an issue. I think the greatest possibility is staying with a 4 core enhanced IPC CCX and pushing the clocks.

A ~ (100-110)mm^2 Zen2 8 core @ 4.5-5.0+ GHz would be a very attractive product.

We are going to see the real ambition of AMD with zen2 (not Zen+ pinnacle ridge H1 2018).
Im hoping for some major improvements to uarch, AVX256, maybe double L2, 12mb L3, 6 core CCX, 4x SMT, increase in execution units making the core wider? Maybe some special low latency optimised hbm L4 cache for sever or on CCX for APU?
If that gives 15℅ IPC lift, plus an 15-20℅ increase in SMT yield and a 10℅ clock increase over pinnacle ridge for a little more power consumption that would be awesome on 7nm.
Hopefully some improvements to infinity fabric bandwidth and latency as icing on the cake.

I hope they don't go the cheap easy route by keeping 4 core CCX and same width cores to increase clock speed, as we know clocks won't go much higher than 5ghz down the road as processes are scaling better with power consumption than frequency increase, it would be short sighted to have minor IPC bump and push clocks, if they make a wider core that will scale better imo.

Obviously they would have internal modelling and projections of the right Balance, I just hope if there if a close call and a clear choice to make from keeping a moderately wide core and pushing clocks with process or going wider core and minimum clock increase they will take the latter option.
Only if it makes sense of course.

 

[CatMerc]

Wouldn't it make sense for AMD to modify the CCXs @ 7nm to,say, 6 cores each?
It would certainly be a large boost for their sever line (+50% on cores alone).

Starship, the 7nm Zen EPYC CPU, is 48 cores according to rumors.

Options:
1. Each CCX contains 6 cores
2. Each die contains 3 CCX's
3. Each package contains 6 dies

I think option 1 is most likely, as options 2 and 3 massively complicate inter-die and inter-CCX communication. If they want to keep one hop between each die like they have currently, and don't want to increase wiring complexity exponentially.

 

[BradC]

"Easy to reproduce" is kind of wrong, people are still playing hit the pot trying to reduce the test cases to the actual cause.

Sorry, by "easy to reproduce" I should have made clear that I hit it about 10 times a day (at least) on a staging system that I'm really like to put into production. AGESA upgrade made zero difference and I shouldn't have to fart around with different version compilers or options that my UEFI doesn't have in any case. This shouldn't happen on plain old x86 code that works on every other CPU reliably. My point was there appears to be no outward community interaction on the part of AMD and a boat load of people putting relatively reliable test cases together because the bug *is* so damn easy to hit.

Sure it's not a 10 line test case that crashes every time (yet), but AMD would have a bucket load more knowledge and instrumentation at their disposal. I would assume they'd be looking into it, it's just odd to get zero feedback at all.

I certainly could not recommend anyone put a Zen based system into a production environment until they get it sorted. I've seen other processes die the same way gcc does, it's just a lot more "random" and consequently harder to reproduce. That sort of unpredictability does not instil confidence. I'm sure they'll get it sorted, but a quick "hey we are actually really looking into this" would be helpful. So far I haven't really seen that level of engagement.

 

[Jan Olšan]

Option 1 also complicates stuff, though.

The cores in one CCX are according to the block diagrams connected similarly to dies in Naples - each core has a link with each other. You can do that with 3 links per node if you have 4 cores in CCX, but if there were six, there would need to be 5 links in each of those cores - 15 paths in the CCX crossing between the cores, an awful lot of wiring. With 4 cores, you only have 6 paths and just two cross each other.

 

[wildhorse2k]

If they introduce some kind of simplified mesh like Skylake-X has, then 6 core CCX makes sense. Not every core needs to talk to every core directly. But we would lose the sweet advantage of Ryzen - many core CPU that can have low latencies of 4 core CPU if threads are placed correctly.

Option 2 leads to even longer rectangular die or wasted space. Based on this I think either option 3 or 1 (if they solve the link problem well) based on your proposition.

But there is another option you haven't considered. 48 cores can also be done with 3 x 16 cores. 16 cores means 4 CCX in a single square die. That should be easy to do and will also increase performance as cross CCX latencies are expected to be better than cross die. I think this is what AMD should pursue.

With Ryzen/Threadripper/Epyc AMD had no choice and had to use the same die as they were on brink of bankrupcy. But now with funds flowing in they can design 2 CPUs - mainstream one (2 CCX Ryzen) and server one (4 CCX Threadripper/Epyc). I don't think it makes sense to keep increasing core counts in mainstream so soon. They also need 4/6 core options, so they definitely need 2 CCX version.

 

[LightningZ71]

Having more than two CCX units per die breaks the interconnect arrangement between individual Zen dies in an MCM and in 2P in epyc. That would require a wholesale tear up of their interconnect fabric. For platform stability purposes, Zen must keep sockets aND external interfaces the same. This means that improvements are strictly kept in the die. With that in mind, this is what we're left with:

Larger L3
Improved schema for L3
Larger L2
Lower latency L2
More cores in the CCX
Improved DDR4 controller

I don't see them re-floor planning individual cores at this point. Maybe some minor errata tweaks and a touch up on critical paths, but that's it. Now, they can refloorplan the whole uncore as they will have more area to work with in their packages with a smaller feature size. This means that there is room to resize things, like the L3. They can reshape the CCXs into a 3x2 grid, making intercore communications less wiring ugly while still expanding to 6 cores in each ccx. They can even do an 8 core ccx, but I don't think that they would be able to expand the L3 sufficiently to keep 1mb per core in the whole die.