But for consoles, don't we expect they will keep the clock lower to improve efficiency and heat (let alone OC), and most games will be either 720p or 1080p? In this case it's not that unbalanced not to taken it into account.
Predict: The Next Generation Console Tech
- Thread starter Acert93
- Start date
- Status
Well on that matter I was speaking of reviews and looking at price high end graphic cards
Anyway perfs per cycle seems to be a wash.
I was just playing the devil's advocate :smile: But it lead me to this question: what's the potential of slightly underclocking the GK104, lower voltage, and bring the TDP to something usable in a console? Meaning perf-per-watt would be prioritized over perf-per-mm2.Well on that matter I was speaking of reviews and looking at price high end graphic cards
Anyway perfs per cycle seems to be a wash.
About the same as doing it with the 7970?
Which brings in the question of why not use pitcairn which already has a much higher perf per watt.
4 years ago someone from microsoft said to me r.e. xbox / next xbox
"The next one will be harder to program, less like a PC, we can't give it a powerful CPU again - we have to rely on the GPU to help out"
how does that tally with more recent rumours and speculation.
Of course I assumed they meant "not a powerful CPU relative to the future time" rather than not powerful relative to the xbox360.
and it also made it sound like a Cell would fit the bill, BUT the explicit mention of GPU doesn't back that up.
1 OoO cpu (max single core available at the time?) with aos oriented instruction set (i.e. dotproduct) plus a GPGPU could be a nice combination. Sounds unlikely though?
Having to mix multicore/vectorized CPU and GPGPU programming would be a mess I think.
Go one way or the other
"The next one will be harder to program, less like a PC, we can't give it a powerful CPU again - we have to rely on the GPU to help out"
how does that tally with more recent rumours and speculation.
Of course I assumed they meant "not a powerful CPU relative to the future time" rather than not powerful relative to the xbox360.
and it also made it sound like a Cell would fit the bill, BUT the explicit mention of GPU doesn't back that up.
1 OoO cpu (max single core available at the time?) with aos oriented instruction set (i.e. dotproduct) plus a GPGPU could be a nice combination. Sounds unlikely though?
Having to mix multicore/vectorized CPU and GPGPU programming would be a mess I think.
Go one way or the other
The list of off-the-shelf (well, of-the-soft-macro-library) CPU cores is a lot better today than it was 4 years ago. Even with a fraction of the die size and power budget they spent on the 360 cpu, they can put in something much nicer, both in absolute terms and in comparison to what is available at the time.
There's no sense in just one CPU core -- a huge portion of the games to be released use some 3rd party engine like UE3, and those are already split to a few threads. Also, the aforementioned pre-existing CPU cores are mostly all multicore designs.
hey you did quiet a good job at keeping your mouth shut4 years ago someone from microsoft said to me r.e. xbox / next xbox
"The next one will be harder to program, less like a PC, we can't give it a powerful CPU again - we have to rely on the GPU to help out"
how does that tally with more recent rumours and speculation.
Of course I assumed they meant "not a powerful CPU relative to the future time" rather than not powerful relative to the xbox360.
and it also made it sound like a Cell would fit the bill, BUT the explicit mention of GPU doesn't back that up.
1 OoO cpu (max single core available at the time?) with aos oriented instruction set (i.e. dotproduct) plus a GPGPU could be a nice combination. Sounds unlikely though?
Having to mix multicore/vectorized CPU and GPGPU programming would be a mess I think.
Go one way or the other
that makes me wonder about the odds about an APU+GPU. In quiet some regards
an APU could qualifies as a cell's heir.
Yes, the question applies equally to pitcairn... but kepler is fresh and new and exciting
Either way, is next generation hitting a TDP brick-wall, to the point where underclocking to improve efficiency could be a better move than getting the smaller versions of those chips at their maximum clock?
Is the architechture having an impact on the ability to volt it lower, or is it only related to the 28nm process, in other words would both kepler and pitcairn gain the same efficiency when clocking lower?
Shout out to Laa Yosh for finding the "digital foundry archive" (guess I wasn't paying attention). Found this very interesting unknown tidbit
http://www.gamesindustry.biz/articles/digitalfoundry-unreal-engine-evolution
http://www.gamesindustry.biz/articles/digitalfoundry-unreal-engine-evolution
So that Kepler card ran the demo on 1080p after all as opposed to the 720p screenshots from Nvidia site.
Anyway I don't give a damn about Mark Rein's words any more until I see UE4 in the flesh and more concrete spec of nextgen consoles. I just hope everything work out for the best for consoles.
Megadrive1988
Veteran
Any answers to my question above?
Only rumors of course, but based on different rumors AMD has MS 99% surely, Sony isn't quite as sure, but still a lot, lot more rumors say that AMD has Sony too, than nV having Sony
sooo. sounds like present situation evolved past the balancing decisions at the time of my ancient word of mouth.
anyone agree/disagree: mixing multicore, simd, and GPGPU for say game physics would be a bit of a mess.
I see the AMD bulldozer has FMA4 (a much more console-esque instruction), perhaps with a 256bit SIMD would remove the need for GPGPU physics etc ?
256bit SIMD without a scatter/gather instruction would worry me though!
does anyone know if thats likely to materialize in a console cpu.
(i know some ps3 SPU code use a trick of loading AOS data, permuting,operating, storing back but doing that for 256 bit SIMD with tiny x86 regfile would be prohibitive?).
Regarding GPGPU vs cell - I've always conceptually prefered the cell, and regarding the popularity of GPGPU I've heard it said "gpgpu only works well with very smal, simply kernels". Cell IMO is perfect for something like evaluating character skeletons with a well defined working set but still the potential to evaluate quite complex code if you need it
DoctorFouad
Newcomer
Maybe what you are saying is true, and a 90 nm RSX is a 70 watt GPU and the 90 nm CELL is a 50 watt CPU. But that is a consevrative estimate.
what we know for sure is that CELL is less than an 80 watt CPU and RSX less than 100 watt GPU, but exact estimates can only be given by sony or nvidia employees. And I have some remarks on your estimation :
1/ If we assume the wikipedia FF13 estimate is real than we are talking about a 209 watt max power consumption and not 200 watt. (and very possibly games like uncharted 3 and killzone3 would use CELL + RSX at 100% at the same time more often, which could bring max power consumption of ps3 a little bit higher, but tests are needed to verify this).
2/ it is unlikelt that EE+GS are always on (no obvious reason for this, they are not I/O a la ps1 chips in ps2) and even if they are always on, they would be running at idle doing nothing when runnin ps3 games and so consuming almost nothing.
3/ Why only 80% PSU efficiency ? the ps3 PSU is a 380 watt PSU running very comfortably a 209 watt hardware, maybe the efficiency is more than 80%.
Now Look at this thread :
http://www.neogaf.com/forum/showthread.php?t=465532
"Pitcairn (Radeon 7870) is such a good candidate for consoles"
the forumer gave good arguments (I cite):
"Die Size
Die size dictates the cost of manufacturing the GPU. The Pitcairn (7870) GPU is 212 mm². For reference, the Xenos (X360 GPU) is 190mm² without the daughter die and the RSX is 240mm². Remove the PC centric logic from Pitcairn; like Crossfire, Eyefinity, UVD, PCIe and it would probably be pretty close to Xenos' die size.
Power consumption
Peak power consumption is about 115W. Pitcairn is also the highest performance per watt GPU. Hardware.fr undervolted their card and managed to get a power draw of only 95W out of their card. Now take the 2GB of GDDR5 memory or 8 chips out of the equation or about 20W and the TDP of the GPU alone would be closer to 75W. " end of citation
I believe arguing that the ps4 and xbox next wont be powerful enough at the time of their release compared to the pc world (or relatively compared to ps3/xbox360 at their respective time of release), due to technical reasons (unacceptable power consumption for a home console, too big die sizes, too much heat and too big noisy cooling systems, a need for non esthetic unacceptable bigger cases in the realm of consoles…etc) are simply wrong.
Of course there exists a possibility that ps4 or xbox next or both of them wont be as powerful at their time of release as were their predecessors ps3 and xbox360, but if that happens it would have NOTHING to do with technical difficulties and EVERYTHING to do with financial reasons. In that unfortunate scenario It would be a PURELY financial decision from sony or Microsoft (mainly not wanting to lose money on hardware, or even wanting to make a profit on hardware on day one).
I would turn that around - additional CPU cores only makes sense if
A: the code is (ALU + local to core memory) limited. If any other resource is limiting, adding cores adds nothing to performance. In fact, performance typically drops a bit due to contention issues, and sometimes suboptimal coding (in order to reasonable parallelism in the first place).
B: the target problem can expressed, efficiently, in a parallel manner. (<- BIG!)
C: the code is actually written not only to compute in parallel, but can also be load balanced well, otherwise you will have "heavy" thread(s) that in practise is rate limiting vs. lighter threads. Might as well have used fewer cores.
D: You are not bitten by Amdahls law, which says that the relative time spent on the non-parallelizable parts of a program will increase as you increase your facilities for parallel execution. It's a mathematical expression, and it is distressingly true.
I've been down in those trenches, but not writing game code, so I wouldn't know how such code behaves. Someone else will need to say, although I guess it will vary a bit both with game, and with the capabilities of the GPU, I guess some parts of what used to be handled by the CPU is now handled by the GPU.
If you launched a console today, it could be viewed as a heterogenous computing platform - the code that requires good single thread performance runs on the CPU, and the code that doesn't, but parallelize easily (with additional caveats) can run on the GPU. It's a pretty good setup. I'm not sure it makes sense to add CPU cores once doing so means that you start to significantly hamper single thread performance (less performant core, smaller cache/core, contention, lower clocks...). I've seen game developers offer different opinions on this, where the ones that were most in favor of more CPU seemed to use it for graphics tasks, rather than game logic. I'm not sure how important that will be going forward in the greater scheme of things.
archangelmorph
Veteran
Huh?
Of course multi-core makes sense!
Far more so than the marginal gains you'd get from clock-speed increases or higher computational efficiency...
The truth is far too much game code is both embarrassingly parallelizable & much of it contents far too much sporadic memory access patterns to make it even remotely better suited to a GPU...
Then there's the fact that unless your in the PC space exclusively (pretty much nobody these days...), you'll have more than enough work for your GPU to consume before you even start talking about moving more non-graphics related processes over there...
So there really is no choice other than to multiply CPU cores as next generation we'll have ALOT more scene management / LOD systems for instance, which will require more room to coordinate what content needs to be sent to the GPU for processing+visualization, of which there will be gigabytes more of over current gen setups...
You're not going to be able to do that with a single core... Ever...
Of course multi-core makes sense!
Far more so than the marginal gains you'd get from clock-speed increases or higher computational efficiency...
The truth is far too much game code is both embarrassingly parallelizable & much of it contents far too much sporadic memory access patterns to make it even remotely better suited to a GPU...
Then there's the fact that unless your in the PC space exclusively (pretty much nobody these days...), you'll have more than enough work for your GPU to consume before you even start talking about moving more non-graphics related processes over there...
So there really is no choice other than to multiply CPU cores as next generation we'll have ALOT more scene management / LOD systems for instance, which will require more room to coordinate what content needs to be sent to the GPU for processing+visualization, of which there will be gigabytes more of over current gen setups...
You're not going to be able to do that with a single core... Ever...
ok.
The thing that doesn't make sense to me is
generalizing extending the GPU to the extent that people do want to start running physics routines etc on it AND having multicore.
I would prefer multicore to 1cpu+gpgpu, but either of those to multicore *and* a reliance on GPGPU (as per ancient microsoft quote "we must rely on the gpu to help out)
I like the 2 types of parallelism that you get on a multicore-vector-CPU/cell - very natural IMO.. parallelism of both high and low level tasks and conceptually fork/join on 2 levels.
That was my take. With the difference between Cell and SMP on the 360/pc, it made much more economical sense for crossplatform titles to reserve the extra cores for a limited number of graphical tasks.
Sadly in my last environment (RIP..) we went the other route, "dont consider tech issues at design stage, optmize as afterthought" .. and ended up bloating gameplay/logic code resulting in expensive port.
It was tempting to just offload code to the other core than to simd/ilp optimize it but that shot the team in the foot having to then move that code over to Cell ... more complex coding for no real visual gain.
Having to mix multiple types of parallelism (SMP and gpgpu) for update code would be a mess I think for developpers. especially if doing cross generational titles that had Cell to contend with.
agree its better to go for simpler logic/ai/physics and pick up any surpluss on cpu assisting visuals and max out the visuals because they are more scalable (change resolution) to cope with platform differences.
I'm well aware of computational limitations.
The point was that depending on what code you are running and what compromises need to be struck on your hardware, there is a knee where adding cores is detrimental to overall performance. That knee can be at one core, certainly, or two, or four, or 16 or.... Again, it depends on exactly what you want to do.
In the context of a console there are quite severe limitations on both power draw and silicon cost. Therefore, it makes sense to cut adding cores above that knee, and rather do it at the point where spending that silicon budget on something else brings overall better performance. To be embarrassingly blunt, for instance on the GPU or on memory, or the data paths et cetera. Not only is "more cores" not necessarily better at all, but particularly when you have a fixed cost/power budget, and those cores come at the expense of something else.
- Status
Similar threads
- Locked
