Predict: The Next Generation Console Tech

[corduroygt]

Except they would need new compilers because its quite likely they will move from POWER 4 based architectures to POWER 7 which are not binary compatible and are out of order executing. In addition to this, its not like the POWER architecture is without its own legacy shackles so its not 15% vs 0% in this comparison although I don't know the real numbers.

Not only the console CPU's are different than POWER4 or POWER7, but I am not suggesting using an off-the-shelf chip, period. It would be an evolution of the current generation CPUs, with OOE and more caches, a custom design manufactured at TSMC or IBM or wherever it's cheapest. Your suggestion would make a console no different than a PC, where it would quickly get outdated, and this gen consoles got outdated pretty quickly to begin with.

I would also like to see where MMX/SSE are better than using GPU/Cell/Stream processors.

You also don't need an x86 if you're just prototyping on the GPU. You can put the same GPU on a card and stick it in a PC to try out features. The CPU is not the most important piece of a console.

 

[liolio]

Wait, are you suggesting that the Intel GPU inside Arrandale etc. can outperform my 8800GTS or my (Core i3 laptop with ATI 5650) notebook? I really don't think so!

I suggest nothing something may be wrong with the review or the description of the setting.
Edit actually the the review was unclear or more like I misread it, it's more 28fps @1024x768. Anyway change nothing to the rest of my post.
EDIT 2
Actually thank more about it and I don't know how the enormity I wrote did jump to my eyes especially as I read quiet some reviews a few days ago (fermi, hd5750 in corssfire, etc..) Did somebody put something in my cofee?

 

[aaronspink]

Not only the console CPU's are different than POWER4 or POWER7, but I am not suggesting using an off-the-shelf chip, period. It would be an evolution of the current generation CPUs, with OOE and more caches, a custom design manufactured at TSMC or IBM or wherever it's cheapest. Your suggestion would make a console no different than a PC, where it would quickly get outdated, and this gen consoles got outdated pretty quickly to begin with.

And you know what? It would STILL BE SLOWER than the cheapest off the shelf PC processor from AMD or Intel. The CPUs in both the PS3 and 360 are incredibly slow in any real measure of performance.
They were slower than the contemporary CPUs being shipped by Intel and AMD at the time and they've only gotten further behind them.

I would also like to see where MMX/SSE are better than using GPU/Cell/Stream processors.

GPU = graphics. Let it do graphics.
Cell = failure. Hard to program and limited and basically a dead end.
Stream processors = pipedream.

Oh, and with SSE you don't have to DMA off to some other memory.

You also don't need an x86 if you're just prototyping on the GPU. You can put the same GPU on a card and stick it in a PC to try out features. The CPU is not the most important piece of a console.

Actually, the CPU is pretty important.

 

[Blazkowicz]

Stream processors = pipedream.

less of a pipedream than recurring talks about procedural contents or ray-tracing. PhysX does exist . It may fare well with a GPU that supports multitasking like Fermi, and with the controlled, custom software stack of a console. Even though it'll stay limited to the massively parallel problems.

/edit : well, I don't know what you consider stream processors, but I consider what's in GPU to be stream processors.

I agree the CPU is important. It gives you framerates. A GPU (ignoring GPGPU stuff) will give you pixels, but won't give you a framerate that the CPU can't provide.

 

[aaronspink]

less of a pipedream than recurring talks about procedural contents or ray-tracing. PhysX does exist . It may fare well with a GPU that supports multitasking like Fermi, and with the controlled, custom software stack of a console. Even though it'll stay limited to the massively parallel problems.

/edit : well, I don't know what you consider stream processors, but I consider what's in GPU to be stream processors.

Well I consider it what it was defined as when the Stanford project coined the term. Closest thing we've actually seen to a commercially produced stream processor is the Cell SPU design.

 

[corduroygt]

And you know what? It would STILL BE SLOWER than the cheapest off the shelf PC processor from AMD or Intel. The CPUs in both the PS3 and 360 are incredibly slow in any real measure of performance.
They were slower than the contemporary CPUs being shipped by Intel and AMD at the time and they've only gotten further behind them.

So you're telling me that the reason PS3/360 can't do 1080p with 4xAA is because of their CPU's? That's obviously not the case as their CPU's are not really bottlenecking. Also you're saying a launch C2D from 2006 can perform image analysis, MLAA, folding@home, lighting and shadow calculations faster then Cell with all its cores? That's laughable. It may run office and windows faster, maybe your downloaded games and demos would install faster on the PS3, and you could compile your programs, build your projects faster on it, but that's irrelevant on a console. There is no primary console application that will need the strenghts of the x86, and the secondary applications like web browsing, netflix, facebook etc will run just fine, since they run fine on even netbooks.

Face it, ever since CPU's got fast enough for real world tasks, they haven't really been relevant, it's all about stream processing/GPGPU's now. Anyone upgrading their computer would get FAR more benefit from getting an SSD and/or a better GPU compared to replacing their CPU. That's why x86 is not needed for these consoles since they don't do cpu intensive tasks that aren't related to graphics, which are done better by stream processors/gpus, not to mention BC is really important this gen due to many downloadable games that users have in their hard drives and tied to their account.

And while you're quick to call out Cell as a failure like you called Blu-ray a failure in 2005, the stream processing concept will still be carried on by Cell and GPGPU's. More supercomputers are looking to use GPU's, and I still mention a single cell processor can still do the same "heavy lifting" tasks as a six core opteron which is more expensive and uses more power when you comparing the 1st and 2nd place supercomputers. Cell is no magic bullet, but it's paving the way more versatile GPGPU's which will take over.

It makes much more sense to put a lightweight core + gpgpu cores/stream processors for a games console. Besides the GPU doing graphics, a part of the GPU core will also be in the cpu to do the heavy lifting/math, similar to getting another NV graphics card for physx.

I actually cannot think of many things that the CPU is bottlenecking any more. On the Oracle servers that I work on, the CPU's are only 10% loaded, they spend the rest of their time waiting for I/O.

 

[aaronspink]

That's obviously not the case as their CPU's are not really bottlenecking.

They are bottle necking what the programmers can do because they are so slow.

Also you're saying a launch C2D from 2006 can perform image analysis, MLAA, folding@home, lighting and shadow calculations faster then Cell with all its cores?

You mean its ONE core and 6 spus that are complicated enough to use in real life that there are entire teams/divisions dedicated to producing software for them so that they can be used at all?

There is no primary console application that will need the strenghts of the x86, and the secondary applications like web browsing, netflix, facebook etc will run just fine, since they run fine on even netbooks.

Its has nothing to do with x86, it has to do with them being effectively the fastest processors on the planet and having effectively zero NRE plus incredible tool chains and performance tools far exceeding the capabilities of current console CPUs.

Face it, ever since CPU's got fast enough for real world tasks, they haven't really been relevant, it's all about stream processing/GPGPU's now.

yeah, sure, that why things like dynamic physics and geometry work so well on GPUs. What? they can't handle dynamic physics or worldspaces?

That's why x86 is not needed for these consoles since they don't do cpu intensive tasks that aren't related to graphics, which are done better by stream processors/gpus,

AI, physics, dynamic world spaces are all computationally intensive and either don't run or run extremely poorly on GPUs. Games do plenty of tasks that aren't related to graphics that are computationally intensive.

not to mention BC is really important this gen due to many downloadable games that users have in their hard drives and tied to their account.

which means they can be re-downloaded and work fine on another architecture. Or are you so out of it that you don't realize that a lot of the downloaded games were recompiled to work on the PS3 and 360? BC isn't really required as has already been shown by all the console vendors.

And while you're quick to call out Cell as a failure like you called Blu-ray a failure in 2005, the stream processing concept will still be carried on by Cell and GPGPU's.

GPGPU is pretty much unrelated to cell in any way.

More supercomputers are looking to use GPU's, and I still mention a single cell processor can still do the same "heavy lifting" tasks as a six core opteron which is more expensive and uses more power when you comparing the 1st and 2nd place supercomputers. Cell is no magic bullet, but it's paving the way more versatile GPGPU's which will take over.

Cell is doing nothing for GPGPU. NOTHING. Its an entirely different programming model.

It makes much more sense to put a lightweight core + gpgpu cores/stream processors for a games console.

sure if all you want to do is play todays games at higher resolutions. But the future is in things like complex AI, complex interactive physics, and destructible/constructable worlds and geometry which all are dependent on CPU capability. The graphics cores are going to be busy running dynamic graphics pipelines not trying to do things that they do rather poorly.

Besides the GPU doing graphics, a part of the GPU core will also be in the cpu to do the heavy lifting/math, similar to getting another NV graphics card for physx.

The GPU will be taxed as it is just doing the graphics.

I actually cannot think of many things that the CPU is bottlenecking any more. On the Oracle servers that I work on, the CPU's are only 10% loaded, they spend the rest of their time waiting for I/O.

Then you can some rather poorly configured servers.

 

[MfA]

I'd rather they spend some of the transistor budget on a boatload of atom cores with a switched networking fabric Cell might have been too hard to program due to it's cache and DMA limitations, but it's still the right idea IMO. I'd say one wide superscalar core is perfectly enough, After that it's time for higher density architectures ... now of course development costs might still make simply going with some multicore COTS processor the better deal, but I'd prefer to see something a little more elegant.

 

[liolio]

A tiny question, do we need more serial performances in a gaming device than say what the Wii Broadway processor offers?

 

[corduroygt]

They are bottle necking what the programmers can do because they are so slow.
You mean its ONE core and 6 spus that are complicated enough to use in real life that there are entire teams/divisions dedicated to producing software for them so that they can be used at all?

There are FAR more developers and companies developing for x86, yet we haven't seen anything like what was being done on the cell being done on C2D. A computationally intensive task such as folding is much slower on a C2D then the cell, or I believe it has also been compiled to work on GPUs, which also destroy C2D.

yeah, sure, that why things like dynamic physics and geometry work so well on GPUs. What? they can't handle dynamic physics or worldspaces?

Cell does AI just fine as seen in KZ2, the 360 cpu does AI just fine as seen in Halo 3, physics can be handled by GPU's as seen with physx, so no, we don't need amd/intel cpu's for those either. In fact cell's are used as physics simulators in supercomputers, so you're wrong there too.

AI, physics, dynamic world spaces are all computationally intensive and either don't run or run extremely poorly on GPUs. Games do plenty of tasks that aren't related to graphics that are computationally intensive.

I showed you examples where AI and physics are calculated on other than CPU's. I would still like to see one task that needs the high integer performance of an x86 on a console game that can't be done on a console cpu.

which means they can be re-downloaded and work fine on another architecture. Or are you so out of it that you don't realize that a lot of the downloaded games were recompiled to work on the PS3 and 360? BC isn't really required as has already been shown by all the console vendors.

PS3 and 360 both have non x86 architectures. They would have to be recompiled to work on x86. BC is much more relevant due to digital downloads this gen.

sure if all you want to do is play todays games at higher resolutions. But the future is in things like complex AI, complex interactive physics, and destructible/constructable worlds and geometry which all are dependent on CPU capability. The graphics cores are going to be busy running dynamic graphics pipelines not trying to do things that they do rather poorly.

All the stuff you listed can be done with console CPU's and stream processors, in fact SPU's are used for a lot of those things you listed. And while the architecture of GPGPU's are different than Cell, they can be used for the same purpose. The only limitation I see there is one of memory when doing destructable worlds.

Then you can some rather poorly configured servers.

No, the budget only allowed for a slow SAN, not under my control.

 

[function]

And you know what? It would STILL BE SLOWER than the cheapest off the shelf PC processor from AMD or Intel. The CPUs in both the PS3 and 360 are incredibly slow in any real measure of performance.
They were slower than the contemporary CPUs being shipped by Intel and AMD at the time and they've only gotten further behind them.

If you look at multiplatform games, the 360 (and PS3) actually hold up well against the fastest Intel or AMD CPU's from 2005, just so long as the games are highly threaded and actually use most of what they have to offer.

Take a game like Lost Planet, or Resident Evil 5, or GTA4, or even something like Dragon Age, and you can see the 360 giving an FX-60 or a 2.2ish gHz C2D a run for it's money, and that's despite the tiling penalty in lots of games too.

So if you go by the performance of actual games then Xenon in 2010 is standing up well to almost any CPU from 2005 and most from 2006.

 

[Squilliam]

If you look at multiplatform games, the 360 (and PS3) actually hold up well against the fastest Intel or AMD CPU's from 2005, just so long as the games are highly threaded and actually use most of what they have to offer.

Take a game like Lost Planet, or Resident Evil 5, or GTA4, or even something like Dragon Age, and you can see the 360 giving an FX-60 or a 2.2ish gHz C2D a run for it's money, and that's despite the tiling penalty in lots of games too.

So if you go by the performance of actual games then Xenon in 2010 is standing up well to almost any CPU from 2005 and most from 2006.

Im pretty sure that most well implemented PC titles actually make quite good use of the CPU resources on a Core 2 Duo. In fact I have an HD 5870 hooked up to a PC right now sporting a 2.4Ghz model. That CPU came out in a comparable timeframe to the Xbox 360. For me the PS3 came out in March 2007, so why not compare that to a Core 2 Quad? It is fair to look at the overall timespan after all.

The CPUs from the same eras of the consoles actual release dates have held up pretty well. I could probably have used the Core 2 Duo for at least another year, had I not upgraded to a Saphire Vapour X 5870 that is!

 

[Blazkowicz]

It may run office and windows faster, maybe your downloaded games and demos would install faster on the PS3, and you could compile your programs, build your projects faster on it, but that's irrelevant on a console. There is no primary console application that will need the strenghts of the x86, and the secondary applications like web browsing, netflix, facebook etc will run just fine, since they run fine on even netbooks.

Face it, ever since CPU's got fast enough for real world tasks, they haven't really been relevant, it's all about stream processing/GPGPU's now. Anyone upgrading their computer would get FAR more benefit from getting an SSD and/or a better GPU compared to replacing their CPU.

A tiny question, do we need more serial performances in a gaming device than say what the Wii Broadway processor offers?

what about the main rendering thread, that does the scene graph thing and fills the command buffer?
I believe it's single threaded. Or at least it used to be.

Sure console games have made progress, in the beginning you had quake 4, with a very slow performance on xbox 360.
Not sure that CPU are fast enough : I have an athlon X2 245, and when I'm accessing the internet through a wired connexion, I'm CPU-limited when loading web pages. (that has to do with extremely heavy javascript, even with the JIT compilation)
I'm not sure that system would do 100 fps under any random multiplayer game either (such as Source engine based ones)

 

[corduroygt]

For me the PS3 came out in March 2007, so why not compare that to a Core 2 Quad? It is fair to look at the overall timespan after all.

Because both console cpu's cost far less and use less silicon than a C2Q. Regardless of when it came to your country, the console was released in 2006, where the best x86 option would be the lowest cost c2d available, which would be E6300 with 2MB cache and 1.86Ghz at a price of $186 in quantities of 1000.

It should be obvious that a PC with a 1.86Ghz E6300 and a crippled 7800GTX cannot run GOW3 level graphics, or do anything gaming related better than a PS3.

 

[liolio]

what about the main rendering thread, that does the scene graph thing and fills the command buffer?
I believe it's single threaded. Or at least it used to be.

I should check but if my memory serve right in directx11 /360 there is one main thread that spam threads which fill command buffers.I will search later for the Ms presentation on the matter.

Sure console games have made progress, in the beginning you had quake 4, with a very slow performance on xbox 360.
Not sure that CPU are fast enough : I have an athlon X2 245, and when I'm accessing the internet through a wired connexion, I'm CPU-limited when loading web pages. (that has to do with extremely heavy javascript, even with the JIT compilation)
I'm not sure that system would do 100 fps under any random multiplayer game either (such as Source engine based ones)

Overall the faster the better, that's why JC and others have been complaining, CPUs are not fast enough and you have to parallelize workloads that are not explicitely parallel. Perfs per CPU cores don't follow Moore's law at all, that's why even on high end X86 Ms came with the same model used on the "weak" 360 cpu, there is no choice. My point was more like for a game were updates happens somewhere between thirty and sixty per second and as you will have to spread workload on multiple cores which is minimal perf CPU core one could live with?
Obviously faster CPU mean gain in productivity and better perfs but at which point do you reach dimishing returns.
I also want to make a difference between slow and broken, for example the Wii CPU doesn't seem broken, Xenon has a lot of issues it seems LHS, cache trashing, poor prefetching ability. I'm not talking about how one CPUs handles bad/spaghetti/branchy code for example. I guess this problems are even more bothering for devs than the pretty low perfs, I feel like devs could live with low serial perfs but the CPUs has to run as expected in most case.

Overall my point is at which level of perfs per core a homogeneous design can pretend be the only brain of a system.

 

[Blazkowicz]

K8 and core2duo set the bar imo, while Atom or X360/Cell PPE fall short.
in my view OOOe is probably needed for the expected performance you call for. branchy code probably can't be written off as bad - you'll need more AI, and sparse-tree kind of data structures.
It will be interesting to see how the AMD Bobcat CPU core works out.

 

[Squilliam]

Because both console cpu's cost far less and use less silicon than a C2Q. Regardless of when it came to your country, the console was released in 2006, where the best x86 option would be the lowest cost c2d available, which would be E6300 with 2MB cache and 1.86Ghz at a price of $186 in quantities of 1000.

It should be obvious that a PC with a 1.86Ghz E6300 and a crippled 7800GTX cannot run GOW3 level graphics, or do anything gaming related better than a PS3.

The assumptions about the cost of the CPU are based on when and how you pay for them and what exactly you pay for. With X86 you pay for the ability to run general purpose X86 code which is one of the industry standard architectures. Its quite likely in a cost+ scenario the X86 CPUs from Intel/AMD at the time would have cost less per unit to make than the equivalent Cell/Xenos processors however such a scenario was not forthcoming in the current generation. In the next generation however AMD is free to license the technology to Microsoft/Nintendo/Sony etc.

 

[MfA]

in my view OOOe is probably needed for the expected performance you call for. branchy code probably can't be written off as bad

OOOe isn't that relevant to branchy code, a sophisticated branch predictor helps but a lot of the time trying to predict all branches with it is far from optimal. A software settable BTB like Cell or even Itanium is pretty much a requirement for calling the architecture optimized for branchy code IMO. In fact OOOe gets in the way a bit, if you really have a lot of unpredictable branches a short pipeline is of utmost importance (it reduces the number of cycles ahead of the branch you need to set up the branch target in code and the bubble when you simply can't and the normal prediction gets it wrong).

 

[nAo]

Unless you have a semi-decent number of threads to pick instructions from.. at that point you don't need to care anymore about predicting branches.

 

[MfA]

Context storage is not free (especially with register renaming) and more threads means more cache pollution. A set branch target instruction and a rudimentary branch predictor are simply nice to have, they don't cost that much.