Predict: The Next Generation Console Tech

Status
Not open for further replies.
Why do people always take extreme possibilities for the next-gen consoles and not feature on hardware that is available now? A much more likely candidate for a future console.

Why would Sony or Mictosoft take a risk with LRB for instance. the graphics part should (if it does this time) come out in h2 2010 or in 2011. Why would they take a risk with a part that has no realistic release date and risk your own hardware on that.

This has been discussed a bit. e.g. Larrabee is an unknown in regards to GPU performance and it is an unknown if the new algorithms it opens up are easy to impliment and offset any performance pitfalls in the "standard" DX rasterizer setups.

Cell is a good example of how a new design concept caused some initial hurdles. Some design tweaking could have offset that (e.g. 2 PPE and 4 or 5 SPEs), but how much of a gamble will companies take?

I think that Sony and Microsoft will take a leaf out of Nintendo's book and go with cheaper hardware (albeit more powerful then current gen) and expand on their touch/gesture/movement controllers. Why wait for certain 22nm parts when 32/28nm should be cheaper, less risky and I think that Sony doesn't want to repeat the PS3 launch.

MS was able to fit fairly competitive hardware in 2005 at a $300/$400 price point.

I would be shocked if all companies go "Wii-style" on us. If MS or Sony keep similar power, heat, and silicon budgets and the other is less progressive they are essentially conceeding the high end to the competitor.

Or put different, we could have 1 360/PS3 console and 2 Wiis in the market. So instead of 50% of users being split between the 360/PS3 and 50% with the Wii, you would see a flip flop--and everyone would say graphics shouldn't be ignored!

Everyone will have casual interfaces next gen, but that doesn't mean that the market who cares about cutting edge games disappeares.
 
This has been discussed a bit. e.g. Larrabee is an unknown in regards to GPU performance and it is an unknown if the new algorithms it opens up are easy to impliment and offset any performance pitfalls in the "standard" DX rasterizer setups.
There's also the possibility of rendering smarter, not hardware, and with lower peak performance getting better actual results.

MS was able to fit fairly competitive hardware in 2005 at a $300/$400 price point.
And if Sony hadn't gone with BRD, they'd have been similar.

Everyone will have casual interfaces next gen, but that doesn't mean that the market who cares about cutting edge games disappeares.
There's also the possibility of gamer 'maturation' from the Wii sector. We all started on 2 axis controllers, single fire-buttons, or maybe a D-pad and 2 buttons. the hardcore gamers have grown up with evolving control schemes. The new generation of gamers who are trying it for the first time are starting with an assumed very low level of skills, but as they game more, both their skills and desire for new experiences should increase. Eventually just waving a remote around won't be enough. They'll want more sophisticated interactions which will require more sophisticated inputs and coordination. As long as it's gradual, they should remain gamers. Future hardware will need to be incredibly adaptable to accomodate the myriad of possibilities and not get marginalised.
 
There's also the possibility of rendering smarter, not hardware, and with lower peak performance getting better actual results.

Possible, but still unproven. Who is going to bet a 5-7 year generation on it?

A GPU that has high "normal" performance and is inching toward more programability is a "safer" bet. So it is on the "Larrabees" of the world to convince console makers that it is a good bet.
 
There's also the possibility of rendering smarter, not hardware, and with lower peak performance getting better actual results.

Not sure if it was already been discussed in this thread, but Epic games stated they're making a software renderer for Unreal Engine 4, designed to run on GPUs but completely bypassing the graphics pipeline, using CUDA or C/C++ (possible on Larrabee and Fermi).

http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf

If this is the direction middleware/game developers are going, a properly upgraded Cell could probably compete with Fermi/ATI/Larrabee without the need for too much fixed function hardware being added to it.

For next generation we will likely have some (6-8?) high performance CPU cores (OOOE, cache hierarchy) coupled a lot of smaller/simpler cores (SPE/nVidia/ATI/Larrabee/other). Having both SPE and GPU cores seems redundant at this point.
 
For next generation we will likely have some (6-8?) high performance CPU cores (OOOE, cache hierarchy)
Do we need that many standard cores? If you're adding stream processing units, I'd have thought the need for ordinary processing would be fairly minimal. A couple of strong 3 GHz cores would be more than enough. Unless you're wanting to give developers a 'soft option', where you'll offer some fairly meaty conventional processing with VMX, and a few stream processors for those developers with more nerve. Which would be a pretty schizophrenic design!
 
Unless you're wanting to give developers a 'soft option', where you'll offer some fairly meaty conventional processing with VMX, and a few stream processors for those developers with more nerve. Which would be a pretty schizophrenic design!

The main reason of having a bunch of strong CPU cores is to run on them the code that isn't suited to stream processing (probably stuff like AI and gameplay scripts) or hasn't been adapted yet (pre-existing code). The focus should be on having good performance on code with lots of branches and unpredictable memory acceses, not stream processing.

Do we need that many standard cores? If you're adding stream processing units, I'd have thought the need for ordinary processing would be fairly minimal. A couple of strong 3 GHz cores would be more than enough.

This is actually a good question. What kind of tasks don't run well on the stream processing cores? How much performance is going to be required to meet their requirements in the next generation?

If we're getting only two strong CPU cores, I think they could fit in the same die of the stream processing cores. Using a separete die for only two cores might not be cost efficient, since it would increase motherboard complexity.
 
The main reason of having a bunch of strong CPU cores is to run on them the code that isn't suited to stream processing...
Yes, that's the main reason, although as you replied to, the requirements for conventional processing may be pretty limited,. However, if developers really aren't wanting to reinvent their wheels to get working code, a console company (perhaps Nintendo are the most likely to go this way) may decide to through in some powerful easy cores. However, a need for some streaming performance would need some vecotr processing of sorts in there.
 
Wouldn't the use of GPU cores for general processing mean that it would take bandwidth away from the graphics processing if we assume that there is only a single bus? So the argument wouldn't be one of taking away from peak graphics processing capability per se, but taking away bandwidth from the graphics processing. Isn't this why Cell has its own bus and memory and RSX has its? It has caused problems for developers juggling it about, but would it have been such an issue if each had had 512MB rather than 256MB?

Also, the argument regarding RSX being weak because it does not have unified shaders. Sure, they give greater flexibility in balancing, but if they had placed 20MB of eDRAM on RSX with similar bandwidth to that enjoyed by Xenos 32/256, would it really be considered to be that weak in comparison?
 
For next generation we will likely have some (6-8?) high performance CPU cores (OOOE, cache hierarchy) coupled a lot of smaller/simpler cores (SPE/nVidia/ATI/Larrabee/other). Having both SPE and GPU cores seems redundant at this point.

Having SPE-like stream processors on the CPU are perfect for doing lots of fast heavy lifting for both general & specific game code without having to suck up unnecessary bus bandwidth trying to shunt it over to the GPU when you already have more than enough graphics related tasks going on over there...

There really isn't a GPU that would make the inclusion of parallel streaming vector processors in a games console redundant. Especially when there's alot more to games code these days than pixel/vertex shaders..
 
Also, the argument regarding RSX being weak because it does not have unified shaders. Sure, they give greater flexibility in balancing, but if they had placed 20MB of eDRAM on RSX with similar bandwidth to that enjoyed by Xenos 32/256, would it really be considered to be that weak in comparison?

Sure but it didn't have it so the argument is rather fruitless..

If anything the lack of a unified shader architecture hurt the RSX more than alot of it's other problems..
 
There really isn't a GPU that would make the inclusion of parallel streaming vector processors in a games console redundant. Especially when there's alot more to games code these days than pixel/vertex shaders..

It would be redundant in cases where you don't use your dedicated streaming vector cores. If that silicon real estate had been in the GPU it could be used for rendering purposes.

Edit: Acert already pointed this out on the previous page. Sorry, I'm reading threads backwards.

The biggest obstacle to using GPGPU in game code is still latency: The turn around time is currently too large from submitting a number crunching task to getting the result. Fermi can probably do something about this, since it apparently can run seperate contexts on each thread processor. You could then run your GPGPU fizziks on 3 out of 10 thread processor for example and achieve lower latencies.

Cheers
 
Last edited by a moderator:
It would be redundant in cases where you don't use your dedicated streaming vector cores. If that silicon real estate had been in the GPU it could be used for rendering purposes.

Edit: Acert already pointed this out on the previous page. Sorry, I'm reading threads backwards.

The biggest obstacle to using GPGPU in game code is still latency: The turn around time is currently too large from submitting a number crunching task to getting the result. Fermi can probably do something about this, since it apparently can run seperate contexts on each thread processor. You could then run your GPGPU fizziks on 3 out of 10 thread processor for example and achieve lower latencies.

Cheers
Sebbbi also made this issue clear. By the way did you read this presentation from Dice/ Repi's blog? It's really interesting I'm sure you'll like it ;)
 
It would be redundant in cases where you don't use your dedicated streaming vector cores. If that silicon real estate had been in the GPU it could be used for rendering purposes.

But like I already pointed out, we don't just want to do rendering tasks. From experience the SPUs are extremely useful for general purpose processing & (in the vast majority of general use cases) the lack of shared cache and branch prediction doesn't hurt nearly as much in practice as one might think due to the fact that they're just so damn fast.

I just don't see how more GPU silicon could be anywhere near as useful (nor as flexible) to me for non-rendering related processes as more SPU-like CPU cores with fast access to main RAM & no GPU bus spamming, slowing down my gazillion render tasks..
 
Err, wait a sec. Quick sum up.
1. Small % of die space dedicated to OoOE
2. stream prcoessors to handle what they are very efficient at handling to make up the rest of the CPU
3. GPU that is more flexible for GP use if a dev so chooses

With the love for a single large pool of memory, how is one going to set up enough bandwidth to handle that setup? If the GPU will be set up to handle more than just the usual graphics load, aren't there going to be issues going back and forth? The aforementioned latency issue? Basically, if the above is the case, and you put in a UMA, then aren't you asking for serious banwidth issues?
 
Last edited by a moderator:
Not sure if already posted on B3D. According to this article Sony has made some decisions on PS4:

http://fgnonline.webs.com/

- 6 - 8 cores PowerPC7 core, 4 threads/core
- 24 tot 32MB shared L3-cache
- 200 double precision-Gflops

- GPU from Imagination Technologies, a 6th gen architecture

They also mention that IBM pulled the plug from further Cell-like developments because SCEI wanted to move
to more traditional architecture.

Now I wonder.. if a developer wrote optimized code for the Cell with its SPUs, can this be 1-1 ported to the PS4 CPU ?

It would be a huge mistake for Sony, in my view, to break backwards compatibility again.

BTW... suppose both Microsoft and Sony decide to stick with IBM what's the difference between:

Xbox: n x PPC7 cores + amount of L1, L2 and L3 cache together with GPU from Nvidia/ATI/Imagination doing DirectX/XDNA
PS3: m x PPC7 cores + amount of L1, L2 and L3 cache together with GPU from Nvidia/ATI/Imagination doing OpenGL ES

at the architecture level we are almost talking about the same thing or do I miss something ?
 
Last edited by a moderator:
BTW... suppose both Microsoft and Sony decide to stick with IBM what's the difference between:

Xbox: n x PPC7 cores + amount of L1, L2 and L3 cache together with GPU from Nvidia/ATI/Imagination doing DirectX/XDNA
PS3: m x PPC7 cores + amount of L1, L2 and L3 cache together with GPU from Nvidia/ATI/Imagination doing OpenGL ES

at the architecture level we are almost talking about the same thing or do I miss something ?

there's less incentive to make custom and weird hardware for consoles nowadays. ended are the days of sprite scaling chips, proto-GPUs, experimentation of vector units/SPU in sony consoles etc.
nowadays it seems it's more important to just have an efficient CPU and an efficient GPU, and there's now only a handful of players in those arenas for high performing parts.

In a way consoles go back to the pre-SNES, jaguar etc. era. Most consoles consisted in a CPU (6502 or Z80), a small amount of ram and that's all. or the megadrive/genesis would have a 68000 and a Z80). all extremely generic CPUs.
In the 90's there was a huge technological explosion, disruptive new capacities all the time, and custom chips (such as the SNES sound chip or playstation's 3D hardware) made the day.
Now it's stabilized again. Current gen was more a continuation of the previous one.

still the same frantic pace of progress mind you but consequences seem not so big.
 
there's less incentive to make custom and weird hardware for consoles nowadays. ended are the days of sprite scaling chips, proto-GPUs, experimentation of vector units/SPU in sony consoles etc.
nowadays it seems it's more important to just have an efficient CPU and an efficient GPU, and there's now only a handful of players in those arenas for high performing parts.

You talk as though the current generation is long since over :) lol

I'm not even sure i agree with you there with the direction the industry's HW makers seem to be going in. In fact i'm sure that we'll see some rather "customised" things next-generation with regards to the console hw architecture.

Also, just to point out, both the PS3, Wii and Xbox360 HW are still very "custom" when compared to PC parts. Yes, the PS3's hardware was the most "exotic" to the platform's own detriment, but I can still see some of the elements of it's basic design philosophy carried over to PS4.

I think at the end of the day, next-generation Sony and Microsoft will try to give the game devs more of 'what they want' next time around. As at the end of the day a console will live or die on it's software, and the game devs are the producers of such ;-)
 
Status
Not open for further replies.
Back
Top