Predict: The Next Generation Console Tech

Status
Not open for further replies.
I think that's the reticle limit, which is the upper limit on what can be manufactured. It's not a limit a console manufacturer would want to approach.
 
I'd consider 300mm^2 to be big. Cypress is 334mm^2 and consumes north of 175W at load. I think [H] measured 222W. Anyways, the TDP is 188W.
 
I'd consider 300mm^2 to be big. Cypress is 334mm^2 and consumes north of 175W at load. I think [H] measured 222W. Anyways, the TDP is 188W.

Would I be correct in assuming that you can't expect the SOC conversion of a discrete 150mm^2 CPU, and a discrete 250mm^2 GPU to be 400mm^2?
 
Would I be correct in assuming that you can't expect the SOC conversion of a discrete 150mm^2 CPU, and a discrete 250mm^2 GPU to be 400mm^2?

Probably not. Theres other stuff that needs to go in there, NB, sound chip(maybe), SB, ect. If those were your two main parts, probably can figure 20-40mm^2 of other crap that has to go in there. I doubt they would ever go for something that big. Probably aiming @300mm^2 or so is reasonable, maybe even smaller.
 
Right... there will be a need to rearrange the layout so that it's optimal for making a rectangular die as you shouldn't expect one side of the CPU to line up exactly with one side of the GPU. Then there's the I/O to each processor's respective RAM pools as well as to one another so just putting two chips together isn't going to work per se.

It'll depend on what you're trying to achieve by merging the two or if there even is a second interface to RAM. Waternoose accesses RAM via Xenos, but other CPUs will naturally have some I/O to DDR3 or XDR for example. There are clear advantages to UMA so... there will be some design changes. Llano only accesses DDR3, for instance.

Now, as a monolithic design, that allows for a wider bus to RAM, but then they'll have to figure out just how small they expect to shrink the chip in the future, and whether or not to start out with your modest 128-bit or 256-bit interface; FWIW, the smallest 256-bit designs have been upwards of 190mm^2.

Also, starting out with a larger die has implications to yield, manufacturing, clock speeds, TDP, and so on compared to producing two smaller chips, especially if you expect eDRAM, which has different requirements over your regular CMOS stuff. Xenos's history so far is the perfect example.
 
Sounds like a SOC design for the next xbox is seriously going to be much weaker than having discrete CPUs and GPUs just by having much less die space to work with. It'll save them a lot of money down the line though.
 
Now, as a monolithic design, that allows for a wider bus to RAM, but then they'll have to figure out just how small they expect to shrink the chip in the future, and whether or not to start out with your modest 128-bit or 256-bit interface; FWIW, the smallest 256-bit designs have been upwards of 190mm^2.

So the trick would be, with a 256bit interface (e.g. on the GPU and the memory control on the GPU, ala the 360) would be that when the GPU reach sub-190mm^2 to have the CPU and GPU on the same die, bringing your total budget over 190mm^2 ;)

Of course down the road you may have problems... meh, just throw it all on die then :p Oh wait, at 12nm everything goes ape $%#$ crazy so they will be stuck at 16nm forever :oops:

Sounds like a SOC design for the next xbox is seriously going to be much weaker than having discrete CPUs and GPUs just by having much less die space to work with. It'll save them a lot of money down the line though.

You don't save money on a losing console! Yes, I am stumping for total chip budgets ~500mm^2 and 4GB of fast memory. Who want an Xbox 360 HD for 10 years? I love my Xbox a lot, but no thanks.

Ps- I exceeded my 2011 forum contributions so I will return to lurking :p
 
Dice gives its POV on next generation systems. Their part on multi chips (either CPU or GPU) sounds weird to me though.

"At least. Probably more, because it's classic PC technology. We know everything about multi-threading now. We know everything about multi-graphics card solutions now. If someone built a console where the specs are that or more, we have the technology to do something. We could port the game to that console tomorrow."

"The big step is to go from single processor to multi-processor. Single graphics card to multi-graphics card. To multi-memory. Do you do multiple memory pools or one memory pool? Since we can handle both consoles now, we control that as well. We have all the streaming systems. We have whatever we might need for the future.

Multi-GPU consoles? This is madness. No, this is Next Gen!
 
Yeah, I gather he's just trying to pimp the engine's future viability for a number of scenarios rather than hinting at real specs. ;)
 
Would it make any sense at all to go with a smallish dual core CPU and a big fancy GPU, all on one SoC? For the CPU I'm thinking two decent OoO cores with a shared L2 (something that should still easily outperform the current console CPUs and be easier to program for) and the GPU something powerful and versatile like Fermi or GCN. The CPU handles the things that the GPU is inefficient with, but most of the heavy lifting (rendering, physics, ...AI?) is all done on the GPU.

Perhaps GPU hardware is still too focused on rendering to make this a feasible solution; I really don't know where we stand with GPGPU these days.

One thing I would hate to see is NVIDIA getting CUDA on the consoles. That could turn the PC gaming scene into a nightmare, with most games not running or not running well if you are rocking a red GPU. DirectCompute/OpenCL FTW (although from what I hear CUDA is in a much better state currently than either of those APIs).
 
I think at this point it'd be a pretty big step backwards to only go with two CPU cores, even if they were of the Core i7 league, which none of the consoles will ever get let alone considering that other CPU designs are just inferior for all intents and purposes. Just look at how BF3 performs I suppose (compare within the same family and core scaling). Not saying every game will be like that, but who knows...


As for CUDA, I don't think you have much to worry about considering Microsoft's own agenda with DX11+...
 
Sounds like a plan :p
I'm not sure it's an option "CPU-less" system would die to the serial part of the code.
Andrew Laureitzen made a point some pages ago about the advantage of CPUs even in some graphic related tasks if I got that right. Sounds suicidal to me. 2 APUs may be an option, actually in case of multi chips (2 nothing fancy) both Sweeney and Richard favored a "symmetric" design so two APU/fusion chips so they can benefit from low latency communication between the GPU and CPU.

"Larrabee like"or "many throughput oriented CPUs" design while not optimal is possible but I don't think the opposite is possible/or wanted.
 
I think at this point it'd be a pretty big step backwards to only go with two CPU cores, even if they were of the Core i7 league, which none of the consoles will ever get let alone considering that other CPU designs are just inferior for all intents and purposes. Just look at how BF3 performs I suppose (compare within the same family and core scaling). Not saying every game will be like that, but who knows...

Of course I wouldn't expect the CPU cores to be i7 league, but even with the IPC of Conroe they would be a huge step up from the current consoles. They wouldn't have to have as much L2 cache as the desktop PC counterparts, making them pretty small on 28nm.

My line of thought was, if you have two or three decent CPU cores you could use them for the stuff that doesn't thread very well, and the parallel stuff could done on the GPU. My question is, is a modern or 2013 GPU good enough at GPGPU to make this viable?


As for CUDA, I don't think you have much to worry about considering Microsoft's own agenda with DX11+...

I sincerely hope so. Funny thing is, if CUDA were to be in both next gen consoles, this would essentially guarantee the failure of PC gaming.
 
The unified memory architectures in consoles would be well suited to CUDA because we save the steps of copying data into video memory and copying results from video memory back into mem ram.

With embedded dram, this kinds of operation should be even more viable. Perhaps MS is going for an SOC because they were going to dedicate the majority of the die space to the GPU cores? Something like a 20/80 ratio in favor of GPU. ~250 mm^2 for GPU, 50-100 mm^2 for the rest including CPU + EDRAM.

Hypothetical random SOC, need help on this.
22nm
400 mm^2

SOC CPU:
OOE
50-75 mm^2
~500 million transistors
3-4 GHZ
(L3 cache is the Edram shared with the GPU, small l1 and l2 caches)

SOC GPU
~250 mm^2
~4000 million transistors
750 mhz - 1 GHZ

SOC Edram
~25 mm^2
64mb
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top