Next Generation Hardware Speculation with a Technical Spin [2018]

[KeanuReeves]

''Mark Cerny, PS4’s lead architect, told Digital Foundry last year that the realistic limits for a next-gen console GPU would most likely top out at eight teraflops''

Now I know this is from a few pages back but I thought I would add that this is the only sentence that mentions a limit on a theoretical PS5.

"A PlayStation 5 processor can afford to be larger, but not that much larger than Scorpio's, if we're remaining on the 16nmFF node. Mark Cerny's notional eight teraflop GPU seems like the realistic limit for a console processor under these conditions. The issue here is that this would only represent a 4.2x improvement over the base PlayStation 4 and a 1.9x boost over PS4 Pro."

The same source as he provided.

 

[mrcorbo]

Now I know this is from a few pages back but I thought I would add that this is the only sentence that mentions a limit on a theoretical PS5.

"A PlayStation 5 processor can afford to be larger, but not that much larger than Scorpio's, if we're remaining on the 16nmFF node. Mark Cerny's notional eight teraflop GPU seems like the realistic limit for a console processor under these conditions. The issue here is that this would only represent a 4.2x improvement over the base PlayStation 4 and a 1.9x boost over PS4 Pro."

The same source as he provided.

So it doesn't really apply then, since the next gen will be on 7nm.

 

[Deleted member 13524]

If the next-gens were coming at 14/16nm, they'd have released already.

 

[Megadrive1988]

This is really interesting.

AMD - The (Evolving) Master Plan

Was Navi built for the PS5?

 

[vipa899]

Navi still GCN? Might buy a navi gpu next year anyway, Uarch by 2021.

 

[anexanhume]

Navi still GCN? Might buy a navi gpu next year anyway, Uarch by 2021.

This was the presumption. There were only recently rumors that Navi might not be GCN.

It would make backwards compatibility easier if it remained GCN, I would venture.

 

[Shifty Geezer]

What if the talk of Sony's involvement is only in making Navi compatible with GCN as used in PS4? That makes sense to me.

 

[Xbat]

This is really interesting.

Lots of talking without saying much.

 

[Rootax]

Lots of talking without saying much.

Well, he thinks chiplet is the way to go, and guess that, maybe, it's amd/sony's plan all along for the cpu, but for the gpu to (with the io core), and he explains why. I always like Adored videos, some I'm not neutral, but I prefer that to "I think X will happen" without any other infos...

 

[DieH@rd]

What if the talk of Sony's involvement is only in making Navi compatible with GCN as used in PS4? That makes sense to me.

Hopefully they will not be so risk-adverse with CPU side. I want to see unleashed Zen in the "boost mode" rendering of PS4 software.

 

[anexanhume]

Lots of talking without saying much.

You accomplish the task in much fewer words. Bravo.

 

[iroboto]

Well, he thinks chiplet is the way to go, and guess that, maybe, it's amd/sony's plan all along for the cpu, but for the gpu to (with the io core), and he explains why. I always like Adored videos, some I'm not neutral, but I prefer that to "I think X will happen" without any other infos...

We are all trying our best to guess for next gen. I guess in many ways he had to take about an hour to explain his logic through.

The probabilities are not in his favour to this working out though. There are just too many connections being made. If each guess he made had a 50% chance of success with the number of connecting guesses the success rate would drop to dismal numbers.

It’s hard to verify the effectiveness of the chiplet setup though. We haven’t seen it in any other configuration nor have we had the chance to benchmark it.

And how much cheaper is it really? Probably cheaper than a single die, sure, but the combined size is still going to increase costs. Assembly will cost more than a single die. More testing costs more.

If the main reason is chiplet is cheaper than a single die because of fabrication yield (probably true if we look at threadripper) but consoles don’t do things like binning. So I’m not sure if he’s factored that in either. Would they put redundancy in all the chiplets? Just seems like a lot of overhead.

I may be biased but I am thinking consoles are about features and not power. The move to push chiplet design is a call for a lot of power. That generally goes against what I think consoles are about (And imo not exciting). Cheaper hardware with features that developers can leverage to extract performance.

 

[Xbat]

You accomplish the task in much fewer words. Bravo.

At least I didn't make a 30 minute video about it . Sorry if it seems harsh and I probably shouldn't of made the comment it's just how I felt at the moment.

 

[Shifty Geezer]

I may be biased but I am thinking consoles are about features and not power. The move to push chiplet design is a call for a lot of power. That generally goes against what I think consoles are about (And imo not exciting). Cheaper hardware with features that developers can leverage to extract performance.

Is that true? Doesn't a chiplet design actually allow for more features and customised functionality, allowing things like custom processors to be incorporated without having to design them into existing GPUs and CPUs? "Let's grab us some Navi CUs in a GPU, and a Zen CPU, but let's also put in our custom AI matrix processor without having to include it in either the other processors." That should elliminate the overhead of designing and manufacturing full-on CPUs and GPUs.

Can components be used across chiplets even?? Could Sony/MS use binned Zen and Vega processors on the chip, coupled with some extra secret source in areas they feel need additional support (3D audio processor, VR magic processor, BVH hierarchy traversal processor, hardware sprites, blitter, sharp sticks and foul language)?

 

[Jay]

the main reason is chiplet is cheaper than a single die because of fabrication yield (probably true if we look at threadripper) but consoles don’t do things like binning. So I’m not sure if he’s factored that in either. Would they put redundancy in all the chiplets? Just seems like a lot of overhead.

Like everyone, some assumptions/reasoning is required.
Firstly what if you don't think the zen cores will be custom, is there anything in the cores you think would be worth customising?
So if the zen chipplets are the same, you could use ones that have slightly less usable cache, slow bins for example, huge economy of scale of the bat, right away.
The gpu is another matter and would most likely be monolithic.
So it's the gpu that needs the redundancy built in like normal, not the cpu chipplets.

 

[McHuj]

His price assumptions at the end don't make a good case for the chiplet design. $65 cost for both a monolithic design or the chiplet based one. IMO, if that the case it favors the monolithic design since it's most likely to see improved cost gains as yields improve. The design would most likely be easier to move to a 5nm node in the future.

I think if we do see some sort of chiplet based design, it may be just two dies. GPU with the IO and the CPU die linked in a package. The GPU still needs a very wide interface for the huge bandwidth so I'm not sure moving that to a separate die buys you anything.

 

[anexanhume]

Is that true? Doesn't a chiplet design actually allow for more features and customised functionality, allowing things like custom processors to be incorporated without having to design them into existing GPUs and CPUs? "Let's grab us some Navi CUs in a GPU, and a Zen CPU, but let's also put in our custom AI matrix processor without having to include it in either the other processors." That should elliminate the overhead of designing and manufacturing full-on CPUs and GPUs.

Can components be used across chiplets even?? Could Sony/MS use binned Zen and Vega processors on the chip, coupled with some extra secret source in areas they feel need additional support (3D audio processor, VR magic processor, BVH hierarchy traversal processor, hardware sprites, blitter, sharp sticks and foul language)?

Or, down the line after a die shrink, could you make a Pro SKU by simply doubling (tripling/quadrupling??) the number of GPU chiplets, for example? Maybe mix in a new IO die?

 

[AlNom]

MIght run into bandwidth problems rather quickly at that point. A dedicated scratchpad or cache chiplet would be curious though (ala Crystalwell), although I don't know enough about the on-package i/o limitations there either... (hence the existence of HBM/interposers *ahem*)

 

[iroboto]

Is that true? Doesn't a chiplet design actually allow for more features and customised functionality, allowing things like custom processors to be incorporated without having to design them into existing GPUs and CPUs? "Let's grab us some Navi CUs in a GPU, and a Zen CPU, but let's also put in our custom AI matrix processor without having to include it in either the other processors." That should elliminate the overhead of designing and manufacturing full-on CPUs and GPUs.

I’m not sure if it’s true. But I think I agree wth your point that chiplets could enables more features and customization.

But as per Albert Penello’s note on console hardware costs, the price will going down when the amount manufactured goes up. So 1 SOC 10 million chips at $1 per chip we can say.

Versus 1 CPU, 1 GPU, one AI processor, 1 I/O chip. That’s 4x more chips. So you need to buy 40 million chips (10 million each) to make 10 M consoles with assembly costs with the chiplet design, cooling is different I think too, versus 10 million SOC. We can already anticipate that those two chips separately will already surpass the cost of a single SoC.

So i don’t think chiplets will be cheaper and the size of what we’re trying to replace in terms of power output must be massive for chiplets to make sense. Thus i feel chiplets are about power and not features.

Thus for the same number of chips 40 Million chips, the 1 SoC should be cheaper.

At 363mm^2 I don’t think chiplets have a chance. In the 800-1000mm^2 range chiplets probably make a lot of sense.

 

[anexanhume]

MIght run into bandwidth problems rather quickly at that point. A dedicated scratchpad or cache chiplet would be curious though (ala Crystalwell), although I don't know enough about the on-package i/o limitations there either... (hence the existence of HBM/interposers *ahem*)

I would imagine that’s where you introduce a new IO die variant. Or could you successfully partition the GPUs with cache as you suggest, or separate the decode and dispatch from execution dies?