Predict: The Next Generation Console Tech

Status
Not open for further replies.
B/C aside, is there any reason that Sony couldn't use something derived from the Power 7 series, complete with OoOE and all the other bells and whistles?

How useful is OoOE in a console where programmer can fine tune their code ?
 
Depends highly on how good the compiler is. If it's good enough that devs don't have to go too low-level for every bit of code then in-order CPU works just fine.
 
B/C aside, they could use anything they like.

Well presumably nothing from Arm, as I don't think they'll have anything with performance high enough (although maybe the A15?), and I doubt Sony want to be tied to Intel.

I can't see them going with anything other than a high performance part from IBM.

Xenon has ~165M transistors. Dualcore I7 has ~500M. For the budget of one Xenon you could get a bit more than half an I7 core. Cell had ~241MFrom what I understand power7 has a metric ton of extra hardware for stuff that consoles most likely will never need like hardware BCD and all sorts of encryption things.

The Power7 core itself (including 256kB L2) is pretty tiny. It's all the bells and whistles that make it huge (SMP linkage and eDRAM). Just look at the die photo. :p

Oh wow, that's a lot of space for cache. Two memory controllers. Four threads per core. And each core has it's own local area of L3.

Right. So maybe the next console CPUs won't look anything like Power7 then.

If IBM expected to get one or more console contracts this gen, perhaps they've been working on a line of console focused CPUs, sharing 'stuff' prom the Power line where they can. If so, Cafe may be the first glimpse of this. Okay, that's the best I can come up with. :D
 
Depends highly on how good the compiler is. If it's good enough that devs don't have to go too low-level for every bit of code then in-order CPU works just fine.

If you have to wait for something from memory won't it always be faster though? I know there are lots of cases where you can avoid doing this, but if you want to be able to branch and then perform a series of operations based on parts of a large data set then won't it always have a big payoff?

Outside of large scale sandbox games with complex physical worlds (I can't actually think of any on consoles) there's nothing left for CPUs to do to enrich gameplay other than power more complex and believable AI, and I'd like a CPU that did everything it possibly could to make this happen.

Much though I like graphics I really wouldn't be impressed to see CPU post processing done while AI team mates made stupid decisions in relatively simple environments, or behave with a complete lack of subtlety (oblivious to the world ->(MONSTER)-> moonwalk behind a wall while rotating left and right by 15 degrees). Lets throw some brute force processing at that instead of decoding video streams and culling polygons ffs.

My knowledge of AI programming is *very* limited, but my pathfinding and state machines all used pointers and branching and I can't imagine it being as fast on a console as a PC. But maybe that's because I suck and all my code is slow.
 
Right. So maybe the next console CPUs won't look anything like Power7 then.
Definitely. I've never understood why people suggest Power7 when it's a server processor. Well, I guess it's a higher number than other Power cores, so must be better. ;)

Any IBM part would have to got the same route as they have done previously. Optimised cores based on the Power ISA. Without the legacy requirements of x68, Power can be more efficient for a console.

I also wonder if ARM can't be wielded. As long as they have a scalable system where a console could use loads of cores, it could do the job. Effectively being what Cell set out to be, a scalable architecture with portable code between devices, but starting from the power efficient end and scaling up, instead of Cell which started from the high performance end and never managed to scale down competitively. ARM cores are suitably titchy; they'd just need the right topology. this would be the best solution IMO. The same cores could be used in a mobile, tablet, netbook, laptop and console, running exactly the same code, just scaled accordingly, without needing middleware getting in the way of code efficiency. One architecture to rule them all! ;) Combine it with SGX's scalability, and the final console may not be the most powerful, but if it was bytecode compatible with the handheld and tablet versions, it'd offer superb value. Buy one game, play it on all devices you own. Stream content from one device to another. The requirement for a single set of service and application code would make maintaining complex device interactions nice and easy, unlike maintaining a middleware like PSS across very varied hardware.

Edit:
If you have to wait for something from memory won't it always be faster though? I know there are lots of cases where you can avoid doing this, but if you want to be able to branch and then perform a series of operations based on parts of a large data set then won't it always have a big payoff?
There's nothing IOE can do that OOOE can't. OOOE is a developer aid. Developers can throw code at it, and if it's fast enough, great. Job done. Only if it isn't would they then need to get down into low-level optimisation. IOE forces low-level optimisation from the outside, meaning you either need very good coders, or you get slow code. OOOE will fit in better with big developers with a mix of abilities, allowing junior programmers to churn out functional, if not pretty, code that the processor does a reasonable job of running, with critical functions given over to the senior programmers to write. Given the complexity of modern development, a console that can offer cheaper, easier development is going to be attractive.
 
Well presumably nothing from Arm, as I don't think they'll have anything with performance high enough (although maybe the A15?), and I doubt Sony want to be tied to Intel.
I've been wondering how high can one actually clock those newer ARMs. I know the A8 in my N900 has been OC'd from 600 to 1700MHz. With decent cooling I don't think it's out of question to see ARMs at well over 3GHz.
If you have to wait for something from memory won't it always be faster though?
OoO doesn't help that much with it I think. Sure, you can probably fill some idle time when you are waiting behind caches but if you already have to make a fetch from RAM you probably won't have enough work to fill hundreds of cycles. The fetches from caches can probably be predicted by compiler and I think it's possible to make a system that when you need to get something from RAM you switch over to other SMT thread.
 
Combine it with SGX's scalability,

What about GPU candidate for PS4. As much as I like to see SGX in there, I want to know how good is SGX at texturing and shading ? I am also expecting displacement maps and tesselation for next gen, how's SGX at those ?

I can't find any article that give the run down on SGX shader processor, All I know is it uses 32 bit internal colour precision, whether it uses scalar or vector processor, I don't know. Also to me SGX even in the MP16 configuration won't even rival AMD R700 that's rumoured to be in Wii2.

Is Series 6 going to be any better ?
 
That is assuming games would actually use 4xMSAA when emulated instead of using some smarter and far more efficient AA algorithm
It's true that not many games use 4xMSAA for rendering visible graphics, but free 4xMSAA is a godsend for filterable shadow mapping algorithms (variance shadow maps, exponential shadow maps, EVSM, etc).

For example, on an average frame we render four to five 512x512 shadowmaps using 4xMSAA. 512x512 with 4xMSAA uses bandwidth equal to 2048x2048 render target. With EDRAM, the system can provide that bandwidth. The AA is resolved by the EDRAM, so the shadowmap rendering and resolving uses exactly the same bandwidth as 512x512 without antialiasing. With antialiasing you do not need to blur the shadowmap (save lots of cycles there), and you get better quality (subsample precision "blur" helps).
 
What about GPU candidate for PS4. As much as I like to see SGX in there, I want to know how good is SGX at texturing and shading ? I am also expecting displacement maps and tesselation for next gen, how's SGX at those ?

I can't find any article that give the run down on SGX shader processor, All I know is it uses 32 bit internal colour precision, whether it uses scalar or vector processor, I don't know. Also to me SGX even in the MP16 configuration won't even rival AMD R700 that's rumoured to be in Wii2.

Is Series 6 going to be any better ?

As far as i know the SGX does not support SM5. So no tessellation or displacement maps.
 
Is the Cell in the PS3 capable of multi-processor operation? It's wouldn't be a poor idea for Sony to just use three or four of them in the next generation console. That'd reduce production risk and allows Sony to put a machine in front of developers much sooner.
 
Part 3, it seems that larrabee failure pretty much convinced every body that the idea is insane till I'm not.
Intel might not have done the best choices, we heard everything and its opposite about it: it's the hardware that sucks, it's the software, Intel could have actually met its target but the things is still not competitive against high end gpu.
Anyway Larrabee project doesn't looks like an example of good project management, from an outsider pov it looks like a mess, delays because of the software, then hardware have to be scale up another delay, delay adding to delay with in the end something that indeed sucks.
For example we have story about Bulldozer engineering sample that run at under whelming frequencies and it's safe to assume that the real product will get better. As Intel stop the larrabee project, nobody give credit to what the end product could have been. Intel has to have failed on every account, for me without insider informations that sounds like a pretty biased GPU guys take.
As I said it might have been uncompetitive still assuming everything went wrong in the chip design sounds like a stretch.
More importantly Intel may have done bad choice, they may have focused on too many cores, while letting power management out of the design. They had a short scalar pipeline that may not have help with frequency scaling for example.
Another point is larrabee was so late that it shown a lot against the GPUs of the time so Intel had to do what it did. Till in the mean time GPUs hit the ceiling in regard to power consumption. Actually assuming the power budget of a console they hit the ceiling quiet some time ago (and sadly we can't expect next gen system to match best PC rigs of the time...). This has to be taken in account. OK 32 cores @2,5GHz might be crazy hot, a power ogre, etc. but think of 8 cores with power optimization, may the picture different?
Actually though my gross calculations, I realized that a eight core larrabee would have been tiny, assuming bigger cores and a low scaling from 45nm to 32 nm, the chips would still be pretty tiny. You have room to "spread" it, assuming the same power consumption a bigger chip should be easier to cool, I mean power consumption is a bother but the real problem is thermal dissipation, no?

What I want to enlighten is that whereas Intel failed it can't be taken as an argument that the idea is completely fucked up even using nowadays process (for out matter next gen system 32nm process).
 
Any chance they could scuttle NVidia and go with AMD/ATI?

Did NVidia do them any favors with the RSX?

Seems like Nvidia is more preoccupied with the ARM SOC market than pushing GPU forward. Presumably, they no longer have high expectations of revenues from consoles as they did when they first partnered with Sony.
 
They could go with whoever they like but hopefully they choose them and go with something more custom from the beginning rather then what appears to be a late in the game decision.
 
Nobody has mentioned storage medium yet.

Blu-Ray was obviously a big cost in the development of the PS3. FWIW, they won the war, though at a high cost.

Now the trendy thing is digital but the telecom infrastructure won't support multi-gigabyte downloads. Well the infrastructure may but the greedy telecoms have imposed caps.

To get any kind of retail distribution of hardware, they have to distribute software by retail as well. Amazon alone can't move enough consoles and even they would want to sell games.

For the consumer, physical media is a better deal. It can be traded and rented. Now if they priced digital downloads say 50% lower than retail, then there would be no need for used games.

So Blu-Ray is the only game in town for distributing HD content in an affordable physical format. But is it fast enough for resources-limited hardware such as consoles? Art assets for next-gen consoles will presumably be several times larger in data size?
 
I think Blu-ray is likely, and you're right it'll be much cheaper this time around since it's a mature, commodity technology this time around. Even if they decide to go with a modified version with additional layers (for 100GB discs, or whatever) that shouldn't push the hardware price up very much.
 
It's true that not many games use 4xMSAA for rendering visible graphics, but free 4xMSAA is a godsend for filterable shadow mapping algorithms (variance shadow maps, exponential shadow maps, EVSM, etc).

For example, on an average frame we render four to five 512x512 shadowmaps using 4xMSAA. 512x512 with 4xMSAA uses bandwidth equal to 2048x2048 render target. With EDRAM, the system can provide that bandwidth. The AA is resolved by the EDRAM, so the shadowmap rendering and resolving uses exactly the same bandwidth as 512x512 without antialiasing. With antialiasing you do not need to blur the shadowmap (save lots of cycles there), and you get better quality (subsample precision "blur" helps).

Would you give up say a bank of 200 shaders (AMD style) in order to have say another 20MB of ED-RAM on top of everything else? Sure it's nice to have but how much of a tradeoff would you be willing to make to get it, assuming you're designing a system for yourself.
 
i can definitely see Sony going with an improved Cell for ps4

maybe i missed it in a previous thread but why have people who dont foresee an improved Cell (with possibly more SPEs) ignored the benefits to devs (especially multiplat) in regards to PORTING between a ps3 and a ps4 very early in a ps4's lifecycle, eg when ps4 sells ~6-10mil in its first year while at the same time ps3 having an install base of 60+ million

with costs the way they are and likely to increase, devs need to support as many platforms as possible

- familiar tools, familiar architecture, and ease of porting

as for media format, definitely blu-ray, hopefully BDXL
 
Last edited by a moderator:
Status
Not open for further replies.
Back
Top