Predict: The Next Generation Console Tech

Status
Not open for further replies.
one would go back to early x86 CPUs and strip all the SIMD extensions

I don't think I understand. This seems to contradict the inclusion of Altivec and further enhancement with VMX128 in Xenon as well as the very nature of the SPEs in Cell.

I don't think anyone will go as multicore as Sony did with PS3. 4 cores seems to be a safe bet.
No? Intel is introducing an octo-core. Or did you mean the different types of cores i.e. PPE, SPE, GPU pixel shaders, GPU vertex shaders? Or... just the sheer size that eight main cores implies on the manufacturing side?

But on another note, how threaded could a game get? Just looking at the Killzone 2 slides on deferred shading, they mention SPU usage as follows:
  • Display list generation
    • Main display list
    • Lights and Shadow Maps
    • Forward rendering
  • Scene graph traversal / visibility culling
  • Skinning
  • Triangle trimming
  • IBL generation
  • Particles
Some of these sound like they should be done on the GPU, but that's not what I want to discuss.

I imagine that at some point, the typical game won't be threaded so much that each thread is even using up a significant amount of CPU time. Thus there isn't a need to have infinity billion cores. On PC the analogy is the hundreds of threads that might exist, but only a select few actually take up measurable processing time.

I suppose that's the idea behind simultaneous multi-threading or "hyper-threading", which I think we'll still see in the future for consoles as a way to "cheaply" extend the number of threads that may be handled.

I'm still wondering if MS will ask IBM to design something "like" an SPE or go with the full-on multiple cores as Intel or AMD are doing. At 45nm, an eight-symmetric-core chip is going to be huge. Perhaps MS will do another weirdo setup and go with 5 cores with SMT capability, and hopefully with a lot more L2 cache!



At the same time I believe consoles would benefit from some of the virtualization technologies of modern x86 CPUs. Back-compat would be a little bit easier (and safer).
Would that really be worth spending transistors (since we're already talking about customizing an x86 core)?

I'm still not convinced in any way they'll go with an x86 design, let alone a custom-designed one. AMD doesn't seem to have the resources to do a custom design that wouldn't see use in the PC space. And the same reasons for not going with Intel for the 360 probably aren't going to be resolved.

At the very least, they can skip out on VT by extending the Waternoose design. :p
 
I imagine that at some point, the typical game won't be threaded so much that each thread is even using up a significant amount of CPU time. Thus there isn't a need to have infinity billion cores. On PC the analogy is the hundreds of threads that might exist, but only a select few actually take up measurable processing time.

I suppose that's the idea behind simultaneous multi-threading or "hyper-threading", which I think we'll still see in the future for consoles as a way to "cheaply" extend the number of threads that may be handled.
Both Cell & Xenon support software/hyper threading of an impractically-large number of (pseudo) simultaneous threads..
 
I don't think I understand. This seems to contradict the inclusion of Altivec and further enhancement with VMX128 in Xenon as well as the very nature of the SPEs in Cell.
And I claim it's not the best approach. There's a reason for GPGPU section on this forum. In my opinion in the near future there will be no need to do number-crunching on the CPU at all. But that's why most of the SIMD extensions were developed (never programmed PPC but 3D Now!, SSE and SSE2 were introduced for that exact reason: do more additions/multiplications/complex numerical or logical operations in parallel on the chunks of data; that's why they are called SIMD after all).

No? Intel is introducing an octo-core.
For PC market. Ctrl+alt+del - tell me how many processes you have running on your machine. How many services are handled by one svchost? That's not the case with consoles. You can do limited amount of stuff at the same time: you run one game, download stuff in background, perform operations keeping you online on the messsenger.

Or did you mean the different types of cores i.e. PPE, SPE, GPU pixel shaders, GPU vertex shaders? Or... just the sheer size that eight main cores implies on the manufacturing side?
Perhaps instead of guessing you ask a straight question without that venom of yours? :) Which part wasn't clear? Why I believe 4 CPU cores are enough? Because there's more need for data processing on the CPU and because current GPUs are better in that type of operations (or will be pretty soon). There isn't enough middleware yet, but in my opinion it's just a matter of time. Again: simple question is usually better that dissing someone.

Would that really be worth spending transistors (since we're already talking about customizing an x86 core)?
For MS I guess it would. When you introduce a new console to the market, you need software. With 1st/2nd party developers deficiencies Xbox guys need some smart strategy for the start. Cheap hardware and broad backcompat would be a plus: you can sell your 360 to buy Xbox 3, play some new games on it but at the same time you can continue playing 360 titles. Is it worth it? I don't know for sure. I'm sure however taht MS has some advantage in this space which would be great to utilize. After all 360 backcompat is a tweaked Virtual PC.
 
And I claim it's not the best approach. There's a reason for GPGPU section on this forum. In my opinion in the near future there will be no need to do number-crunching on the CPU at all. But that's why most of the SIMD extensions were developed (never programmed PPC but 3D Now!, SSE and SSE2 were introduced for that exact reason: do more additions/multiplications/complex numerical or logical operations in parallel on the chunks of data; that's why they are called SIMD after all).

Fair enough. Thanks for the clarification. Personally, I have issues with having the GPU to do non-graphics work, particularly in a closed system with a single chip. Sure, as a closed-system, developers can tailor the game for it. But if you're doing number crunching on the GPU when it was traditionally done by the CPU, it probably means you're sacrificing something from the graphics side.

Besides, taking away that functionality in the CPU means devs are going to have to re-do the engine come next-gen, which from previous discussion, is something that MS and Sony should try to avoid through their hardware designs.:p

For PC market. Ctrl+alt+del - tell me how many processes you have running on your machine. How many services are handled by one svchost? That's not the case with consoles. You can do limited amount of stuff at the same time: you run one game, download stuff in background, perform operations keeping you online on the messsenger.
I meant on the hardware side, not software. :p

From what I read it sounded like you didn't think anyone at all was going to go with as many cores as Sony did yet Intel already has plans for something monolithic. And keeping in mind that we're all considering x86, it only seemed natural to point out Intel's own doings. :)

Perhaps instead of guessing you ask a straight question without that venom of yours? :) Which part wasn't clear? Why I believe 4 CPU cores are enough? Because there's more need for data processing on the CPU and because current GPUs are better in that type of operations (or will be pretty soon). There isn't enough middleware yet, but in my opinion it's just a matter of time. Again: simple question is usually better that dissing someone.
no no! You misunderstood. I was genuinely not clear, so I was just making guesses... I didn't mean any aggression at all.

Here's what I was thinking at the time -> When you mentioned the route Sony went, I was thinking of the overall PS3 system, not just the CPU. Cell in the PS3 is 8 functioning cores (9 if you count the one they disable), and that's split between the PPE and SPE. But those are not the only types of processors in the system. There's the GPU, which can be further broken down into pixel shaders and vertex shaders, which have different programming methods. In that sense you have four types of processors. So I just confused myself with too much thinking there.


For MS I guess it would. When you introduce a new console to the market, you need software. With 1st/2nd party developers deficiencies Xbox guys need some smart strategy for the start. Cheap hardware and broad backcompat would be a plus: you can sell your 360 to buy Xbox 3, play some new games on it but at the same time you can continue playing 360 titles. Is it worth it? I don't know for sure. I'm sure however taht MS has some advantage in this space which would be great to utilize. After all 360 backcompat is a tweaked Virtual PC.
Actually, I was wondering how many transistors it would take. A hardware implementation to assist VT versus the software emulation they chose for Xbox backward compatibility.

I'm all for backward compatibility, but I just wanted to know if the hardware implementation was significant. If it was, maybe they should just bite the bullet and use software emulation and spend those transistors on something else.

The reason I ask is because Intel had removed VT from the E4xxx line, and it sounded like it was significant enough to optimize the design and take it out.


Both Cell & Xenon support software/hyper threading of an impractically-large number of (pseudo) simultaneous threads..

Sure. I don't disagree. :) Just thinking aloud with respect to the thread topic.
 
Besides, taking away that functionality in the CPU means devs are going to have to re-do the engine come next-gen, which from previous discussion, is something that MS and Sony should try to avoid through their hardware designs.:p
That's the reason why I believe that putting CPU and GPU closer in PCs will make this transition easier. That's something AMD clearly wants to do. There is a valid reason why AMD purchased ATI and I'm sure they will end up with some smart idea on how to bring these two worlds together right. And middleware will emerge and development will become easier. I hope. ;)

I meant on the hardware side, not software. :p
Consoles are about software. :cool:

From what I read it sounded like you didn't think anyone at all was going to go with as many cores as Sony did yet Intel already has plans for something monolithic.
No, no, no. I was trying to say (and failed) that there is no reason to do that (8+ cores) on the consoles. After all this is "Predict: The Next Next-Generation Console GPUs etc" thread.

And keeping in mind that we're all considering x86, it only seemed natural to point out Intel's own doings. :)
But we're talking about x86 for consoles, not general use x86 for Office users with Solitare minimized so boss won't get mad.

Here's what I was thinking at the time -> When you mentioned the route Sony went, I was thinking of the overall PS3 system, not just the CPU. Cell in the PS3 is 8 functioning cores (9 if you count the one they disable), and that's split between the PPE and SPE. But those are not the only types of processors in the system. There's the GPU, which can be further broken down into pixel shaders and vertex shaders, which have different programming methods. In that sense you have four types of processors. So I just confused myself with too much thinking there.
Well, so I was the one who wasn't clear at all. I was talking strictly in terms of CPU and it's place in overal architecture of the console as I have more theoretical and practical background in that area. I have little experience with modern GPUs although I got my master's in programming computer graphics. :oops: I'm not going into that area as there are people on this forums who are able to eat me alive there. The only thing I strongly believe in is that we will have massively parallel general purpose execution units in next gen console GPUs (something like GF 8800 but with cherry on top). This is based on the assumption that some work will shift from CPUs to GPUs (mainly phisics and collision detection). Obviously if I'm wrong with this part, everything I say is a bunch of crap.

Actually, I was wondering how many transistors it would take. A hardware implementation to assist VT versus the software emulation they chose for Xbox backward compatibility.
I guess that in the end what matters is the overal cost of complete solution. Is it cheaper to have more HW and less software (=less people working on back-compat) or the opposite? That depends on HW costs and expected volume of units sold. So yes, in the end it may be more expensive to put some stuff in HW. Another thing is: do we really need backcompat?

I'm all for backward compatibility, but I just wanted to know if the hardware implementation was significant. If it was, maybe they should just bite the bullet and use software emulation and spend those transistors on something else.
True. I have no idea how many transistors it takes to aid virtualization though.
 
As for using the GPU for "general" tasks and "stealing" away from graphics (1) is not the use of the CPU for graphics related activities stealing the CPU away from non-graphics tasks and (2) if there was an understanding of the GPU(s) being a part with broader shoulders and a more general workload, it isn't inthinkable that more realestate be dedicated to the part, maybe even going multi-chip. Instead of roughly 1:1 area budget, maybe a 2:1 ratio in favor of the GPU would suffice? For games with low levels of complexity/demand, there will be less CPU to be idle and more GPU power for graphics; for games with more ambitious goals there will be a very fast (good bang for buck transistor wise) resource at the disposal once all avenues in CPU performance are exhausted. And truthfully, many CPU oriented tasks (animation, physics, particles and deformations, etc) are concievably graphics issues as well. There may be some potential advantages of running certain tasks on the GPU?
 
This is where the ideal solution is flexible cores that can handle graphics and non-graphics functions, whether those cores come as GPU extension or beefed-up SIMD units on the CPU. People are still hung up on a GPU being used for graphics, and thinking use of GPU elsewhere is a 'loss'. It's all just processing resources, to be used as the developer sees fit. Processing can be divided into two workloads - data streaming and 'control code' with all it's jumps and random memory accesses - and the processors of the system have to handle all that as best it can. I don't think architectures will be much more exotic by the next consoles, but they will be eventually. For PS4 we can muse about a Cell variation with nVidia-enriched SPEs. For XB733t we could be looking at a CPU with standard cores and an ATi GPU with much more focus on GPGPU functionality. Or an AMD CPU with inbuilt 'GPU' cores.
 
As for using the GPU for "general" tasks and "stealing" away from graphics (1) is not the use of the CPU for graphics related activities stealing the CPU away from non-graphics tasks and (2) if there was an understanding of the GPU(s) being a part with broader shoulders and a more general workload, it isn't unthinkable that more real-estate be dedicated to the part, maybe even going multi-chip. Instead of roughly 1:1 area budget, maybe a 2:1 ratio in favor of the GPU would suffice?

I do not approve of your post! It's not long enough! :p

On your first point, I don't think it's a major issue looking at it from that perspective. There's basically the game thread, render thread, and all other small duties. In a way, it seems like the idea behind Cell. The SPEs are the number crunchers, and they just happen to be sitting right next to the PPE.

It's interesting you mention the die ratio between the CPU and GPU, but I think ultimately we have to consider that there is a die area budget, and that monolithic cores are not the way to go for a console, particularly when MS and Sony are expecting to reduce the size of them over their lifespan. And for next-gen especially there's a problem of just how much smaller they can make things.

By 2011 they'll have a well-understood 45nm process, and are probably looking at 32nm as soon as possible. But after that there's 22nm and 16nm, and both of those are well within what is generally considered quantum physics territory.

So you can go a few ways with the dice ratio:
(a) Remove the number crunching bits from the CPU and keep the GPU as intended
(b) Add transistors to the GPU to beef it up to make up for what was lost in the CPU, or (c) Have the multi-chip (but MS and Sony probably want the least number of chips in total).

Going back to Cell, the solutions would be akin to:
(a) Removing the SPEs entirely since they are the number crunchers, and then relying on the number crunching GPU (say some unified shader GPU with more GP functionality),
(b) Splitting the SPEs away from the PPE and adding it to the GPU, and
(c) Making it a separate chip.

(obviously there are problems with actually taking the SPEs away, but bear with me).

(a) Doesn't sound good IMO. And do recall, the SPEs are pretty much being used for graphics-related stuff. If they're already using SPEs to do the work, why shift all of that to the GPU?
(b) It's great that you can make the CPU tiny, but the GPU is going to be an even bigger problem in operation -> heat/power. Xenos is bad enough as is!
(c) Multi-chip... they did do that with Xenos. Good for yields early on. Probably don't want lots of different chips though -> manufacturing logistics.

There may be some potential advantages of running certain tasks on the GPU?
Quicker access, parallelism. Perhaps others can chime in. :oops:

I guess that in the end what matters is the overal cost of complete solution. Is it cheaper to have more HW and less software (=less people working on back-compat) or the opposite? That depends on HW costs and expected volume of units sold. So yes, in the end it may be more expensive to put some stuff in HW. Another thing is: do we really need backcompat?

That's the crutch I suppose. To put things another way, it's easier to shrink the size of the team handling software backward compatibility over time than it is to shrink a chip, which has extra dedicated hardware for it (and hence the associated costs). :p

And with respect to the big question of whether or not it's needed, I think the software solution handles it. As you say, BC is important early on, but over time the question gets clear as mud.

For all the little bugs here and there with the current situation with the 360, I think they're doing pretty well. Two years now after their launch, BC seems to be a non-issue. It's great that MS has been supporting it along the way, and they've covered most of the important titles.
 
AlStrong said:
By 2011 they'll have a well-understood 45nm process, and are probably looking at 32nm as soon as possible
Actually Intel will release its 32nm CPUs around 2009, by 2011 22nm should be there.
 
Intel are on 45nm now, where the consoles are just entering 65nm (which Intel have had for ~18 months). Intel are way ahead on the process shrinks. Unless the consoles use Intel chips, they'll be a process behind. I wouldn't be surprised if like this gen they target 32nm but launch on 45nm.
 
Well, if we look at what state IBM and AMD are then of course things are not all that good. IBM and AMD are basically doing the research together and from what I see they are way behind Intel. I wouldn't be surprised if 32nm is not achieved by them by 2010.
 
I will try my estimation based on the overall guesstimated dies size that will available in the next 360 (and anybody with really knowledge on that matter should try to make more accurate estimation than my rought calculations).

I would say around 300mm² @45 nm and I will follow 360 split between cpu and gpuand give my opinion later.

1° First EDRAM
@90nm the daughter chip was ~70mm²
@65nm it could be 35mm²
@45nm it could be20mm²
It would depend on the ratio logic/memory

It would need 3 time more edram to handle 720p +4xAA without tiling

So edram would be ~50mm²@45nm², as memory seems to be tigher than logic.
50mm²could be spent on smart edram

So we're left with 250mm² of silicon.

2° the GPU

I won't use the xenos who was ~180mm² @90nm but newer G92.
the G92 is 420mm² @65nm
the G92 would be 210mm² @45nm

If we cut ROP, VP II engine with how die size are we left? (I've no clue Knowledgeable members welcome again)
i would say arbitrary 180mm².
Quiet a huge chip...
So I think the that the gpu will be tinier than today top of the line Geforce8 (even if it's broken into smaller cores)

125mm² could be spent on the gpu

3° the CPU

So we have at max ~125mm² left for the cpu
(for reference the die of a perryn @45nm is 107mm²).

the xenon take 170mm² @90nm
85mm² @65nm
45nm @ 45nm

So MS could have:

8PPx +4 MB of L2

Or

+8 even simplier cores with more raw power (stronger simd units) and more cache

Or

4/6cores of enhanced PPx: think better branching or better support of SMT or Some OoO implementation, stronger simd units (both floating and integer, wider)

125 mm² could be spent on the cpu

4° balancing GPU and CPU.

So I think MS (and the others) are likely to be on a tigher silicon budget than they were with the 360.

How to make the most out of 300mm² of silicon?

I would bet that the cpu will run around the 3.5GHz.
So to have better performances Ms may need a bigger cpu (it could be more cores, better cores, or both obviously)

If you look at Nvidia Gpu it seems that Gpu have quiet some legs when it comes to clock speed for shader cores.
It's something that would let MS put more silicon in the CPU while allowing for a nice bump in shading power.
May be MS could have a Gpu (shader cores) clocked almost as high as the cpu to save Transistors and die size.

As silicon budget is tigher edram seems costier!
So it has to be efficient and flexible, no tiling that doesn't work well with memexport, some shading technics, etc..

Running after the 1080P will be really costy:
Need huge bandwith => edram or huge bus... money
Pixel shading.

My balancing

I think MS will keep Edram enough for 720p+4xAA ~30MB

Should have a lot of RAM (3/4 GB) to balance the tigh silicon budget and a UMA.

MS could end with a CPU bigger than the GPU (if you put the logic (which should be programmable) included in edram aside)

MS could end with a GPU (mostly shader cores) tinier than we think but clocked really high.

Ms should go with a top of the line scaler.
 
Last edited by a moderator:
Well, if we look at what state IBM and AMD are then of course things are not all that good. IBM and AMD are basically doing the research together and from what I see they are way behind Intel. I wouldn't be surprised if 32nm is not achieved by them by 2010.

Only Intel seems able to push 32nm around 2010, MS will use what is readily available from cheaper manufacturers ie 45nm, the same is true for Sony.
 
On a really technical point, does something prevent "shader cores" to run as fast as modern cpu.

Nvidia is already going pretty high.

The CPU side of next gen have already been discussed in deep (really deep) in the "future of console cpu" thread.

And it's interesting to see that it's always the very iffy question.

It should be interesting to see precisely how the xenon spend its time during game.

I remember graphs that show that rendering and decompression are two huge time consumers, it seems that the AI/physic often come third.

It would also be interesting to know if games are more cpu limited on console than on PC state of the art single thread monsters.
Which part of the game loops hurts? etc.
How MUCH SMT manage to improve IPC on xenon?

It should be intersting if the same people who made so afordmentioned thread so interesting (3dilletante, Nick, Democoder, I know I forgot people) came here to see what is their opinion now that we have more feedback on cell, xenon, more clues on the up coming larrabee, that gpgpu seems to become a real alternative for some calculations, etc
 
Great name, seriously. Xbox 3K became my bet for the next Xbox. ;).
Nice name, indeed, which brings other ideas to birth. I'd also like a name such as Ybox or Ybox 3k, too

I'm almost sure that the console won't have a name like Xbox 3 or something like that because with the 360 MS was apparently worried about the fact of Xbox "2" being numerically compared to PlayStation "3", and coming out inferior.
 
I'm somehow predicitng that (for the PS4), the main CPU would be at 32nm.

Generally, following the trend of Intel's tick-tock initiative (ie. 2-year intervals), it would appear that Intel would release 32 nm by year 2010 and 22nm by 2012. Now since the PS4 would most likely launch in a timeframe of year 2012 (probably Q3-Q4), it would use a 32 nm setup (as consoles are generally one step behind the Intel "tick-tock" strategy).

Sony (and the CELL consortium) would have used 45nm by 2009-2010 timeframe. Therefore, I expect that PS4 would use a step better than that and the closest to it is 32nm (by the 2012 launchframe).

I hope that happens :)
 
@Cyan: it's slightly OT, but I don't think Ybox is a good name. It sounds like "why box?" and gets immediate answer: "you're right, why should I bother about this box if there's PS4 around". ;) Going further Zbox is a horrible name from my POV - it's sounds close to Polish word for "pervert". Lets stick to Xbox, ok?

@Blackraven: I doubt that we will have to wait that long for the next generation of PlayStation. 2012 seems a little bit to late for Sony. I think that this time around they want to start first.
 
@Blackraven: I doubt that we will have to wait that long for the next generation of PlayStation. 2012 seems a little bit to late for Sony. I think that this time around they want to start first.

I doubt that...

Sony are going to want to stick with the PS3 for as long as they can to make sure they establish the console as a success & hopefully turn a profit..

They're not going to be losing money on the hardware forever & it's likely that they're predicting another 10 year lifecycle for the platform, especially since MS have already stated that they're looking towards doing the same..

The Wii really doesn't take away from the playstation's business model as it caters to a separate market & there's nothing stopping Wii owners looking for a HD gaming fix, picking up a PS3 in a year or two when the price has come down and there are more AAA titles out there..

Sony will likely be looking to stick it out for as long as they can with the PS3 and the only reason I can fathom of them having cut it's lifespan shorter than initially projected would be in the introduction of a vastly different platform in terms of the focus, features and capabilities the Ps4 would have to offer..
 
If Sony don't get the market share they want they'll go into the next generation early to try and do what the 360 has managed to do this generation.

Sony can't afford to think about profitability just on the PS3. They'll be thinking abut what's best for next generation too, and will launch in a time frame that suits the PS4.
 
I'm assuming year 2012 would mark a PS4 launch (as long as they stick to their 5-year schedule). By then, they'll keep the PS3 for its last 5 years (before E.O.L.). At least that's what I'm predicting.

You know what. This is reminds me of that topic where we were predicting of a whole new version of CELL for the PS4 (more like a CELL 2.0) where it would have at least double the number of SPEs and will now have 2 PPE processors.

Not to mention the notion that if they release it using 32nm parts by launch, then the Ghz number would already skyrocket. Not that CPU clock speed alone is the end-all & be-all of a CPU system but to achieve a significant boost of clock speed alone would be killer.

I mean, if the jump from PS2 to PS3 was massive (from 266 megahertz...............to 3.2 gigahertz), then what more with the PS4 by year 2012. We should be able to reach 10 Ghz teritorry by then................while still maintaing max power consumption at not more than 300 watts.

It's one crazy-ass prediction: 10 Ghz and beyond while max power consumption not exceeding 300 watts. HOLY SHIT!!!!!:oops:
 
Status
Not open for further replies.
Back
Top