[bitsandbytes]

Originally Posted by TheChefO

If they end up putting a 130mm2 GPU in the box, what makes you think they would put a ~230mm2 (28nm) quadcore Power7 to match it? Who in their right mind would pair such a weak GPU with a quad power7 in a console? When has a console maker ever had such a beefy CPU paired with a GPU half the size?

Are we building a server or a games console?

If they're going that light on the gpu budget, they can save a ton by sticking with a quad PPE/Xenon and call it a day...

Pretty sure the core audience will promptly ignore the wasted retail shelf space and proceed to stick to their existing gaming rig which outclassed such an offering years ago, or switch to one, but thankful for the new dx11 games that will finally make their way to the PC.

Or just stick to the existing console they own.

Maybe I should have said "based" or left "7" off. My point is that I believe they will end up much less cutting edge compared to this generation.

What would be the minimum you would expect spec wise from next gen?

[Ninjaprime]

Originally Posted by TheChefO

If they end up putting a 130mm2 GPU in the box, what makes you think they would put a ~230mm2 (28nm) quadcore Power7 to match it? Who in their right mind would pair such a weak GPU with a quad power7 in a console? When has a console maker ever had such a beefy CPU paired with a GPU half the size?

How are you getting 230mm2? 45nm 8 core Power7 is 576mm2, so just cutting the die in half to 4 is 288mm2. 45nm --> 28nm is only going to shrink 50mm2? Not to mention all the excess server/supercomputing crap and excess cache that would be removed... If it was made for a console 4 Power7-esque cores would probably end up 120mm2 or less at 28nm.

[TheChefO]

Originally Posted by bitsandbytes

What would be the minimum you would expect spec wise from next gen?

The minimum will depend on the MSRP, but assuming $400 is the base target (with premium editions above this) I'd expect at least 250mm2 dedicated to graphics. However, I'm not under the assumption that the ps4/xb720 consoles will not have GPGPU functionality. Some CPU burden will be lifted.

That's why I'm figuring ~300mm2 as the baseline to expect for a gpu as it will not just be a dedicated graphics engine, but will be a gpgpu. Taking a bit of the die budget away from the CPU and shifting it toward the GPU.

With that said, ~100mm2 is what I'm expecting of the CPU. Roughly double the size of current Cell/Xenos at 28nm.

[bitsandbytes]

So TheChefO, you think around ~400mm2 total @28nm. I think around ~250-300mm2.(If Ninjaprime's figures are correct on the CPU)

They will probably end up somewhere in the middle. Now we wait for some proper leaks.

[liolio]

Originally Posted by bitsandbytes

So TheChefO, you think around ~400mm2 total @28nm. I think around ~250-300mm2.(If Ninjaprime's figures are correct on the CPU)

They will probably end up somewhere in the middle. Now we wait for some proper leaks.

I'm more in line with you, and we indeed want more leaks but to me the info about all the early rumors is the lack of words "awesome" "monster" "big" "impressive" etc.
At this stage I'll be happy with the x6 statements turns out true.

I'm still thinking of the possibility of a set-up like AMD "dual graphic" especially after digging more about LLano more precisely about how power varies in regard to variations of GPU and CPU clock speed and the number of SIMD. I'm lacking knowledge: I don't know if disable SIMD array still leak and I still lack data: I should search the web more for serious measurement of llano power consumption with CPU,GPU overclock down clock but I start to build an answer to why it could make sense (not that MS did that but in "theory") to go with an APU+GPU. The answer could be simply that "you can" on the A8-3850 and the A6-3650 running the GPU on top of the CPU at full load cost you only 16/17Watts so ~114% of the system power consumption with the gpu idle (hardware.fr data by the way).

EDIT
Also taking in account the akin hd6670 and the time it may take to put together a proper APU/SoC it's likely that MS would want the SOC GPU and the discrete SOC to share the same architecture (VLIW%, southern island derivative, etc.).

[Solarus]

Saw this debate from the GAF thread, good to see this is being discussed here! Here's a question for you guys. Do you think the nextbox and playstation will use GDDR5 or will they stay with GDDR3?

[McHuj]

Originally Posted by liolio

I'm still thinking of the possibility of a set-up like AMD "dual graphic" especially after digging more about LLano more precisely about how power varies in regard to variations of GPU and CPU clock speed and the number of SIMD. I'm lacking knowledge: I don't know if disable SIMD array still leak and I still lack data: I should search the web more for serious measurement of llano power consumption with CPU,GPU overclock down clock but I start to build an answer to why it could make sense (not that MS did that but in "theory") to go with an APU+GPU. The answer could be simply that "you can" on the A8-3850 and the A6-3650 running the GPU on top of the CPU at full load cost you only 16/17Watts so ~114% of the system power consumption with the gpu idle (hardware.fr data by the way).

I think a dual APU/GPU setup could make sense in a two SKU system: a low priced tier consisting of only the APU that runs only Kinect, XBLA, and Apps (maybe without an optical drive as well) and a system with that SOC but an additional GPU for the triple AAA games. Perhaps the second GPU is eventually merged into the SOC after a die shrink (or two).

I don't think that this would be an efficient implementation, but I guess it's a possibility.

[liolio]

Originally Posted by Solarus

Saw this debate from the GAF thread, good to see this is being discussed here! Here's a question for you guys. Do you think the nextbox and playstation will use GDDR5 or will they stay with GDDR3?

Sorry I don't get which debate you're speaking about, die size or dual graphics kind of solution?
For ram GDDR3 won't happen. It's either ddr3+ edram or gddr5 with low odds cor something rambus based.

[AlphaWolf]

DDR4 could be a possibility, I believe Samsung started sampling last year.

[liolio]

Originally Posted by McHuj

I think a dual APU/GPU setup could make sense in a two SKU system: a low priced tier consisting of only the APU that runs only Kinect, XBLA, and Apps (maybe without an optical drive as well) and a system with that SOC but an additional GPU for the triple AAA games. Perhaps the second GPU is eventually merged into the SOC after a die shrink (or two).

I don't think that this would be an efficient implementation, but I guess it's a possibility.

I don't like this idea of different SKUs (to begin with) with that much disparity in characteristic.
There were rumors about MS going that route as well as announcement to be made by the CES, so far it's been proved BS.

I think that the second GPU could indeed get merged down the road but it has implication on the memory organization. IF the second GPU has it own ram and most likely is connected to it by 128 bits bus once the whole stuff put together the resulting chip will have to accommodate for two 128 bits bus which has strong impact on the chip minimal size.


Some pages ago I considered that both the SoC and GPU could be on the same as xenos and its daughter die and connected with a high bandwidth link. Problem is I don't know what kind of bandwidth can be achieved at reasonable cost

Case 1. We might want something like 64GB/s ie as much as the HD6670 is provided with if the second gpu is completed (ie ROPs are on chips).

Case 2. If in the end the second GPU is incomplete akin to Xenos and all the ROPS are on the SoC die I don't know how much bandwidth would be needed to make things workable. I fished for information about it earlier and so far I got answer. FYI I though that the bandwidth requirement would grow with the number render targers, their resolution, and the precision used for colors.

I tried to think more about it and here is my "thinking flow":
If Ms sticks in face of enthusiasts and most likely marketing division to 720P rendering a 32GB/s or a bit more link as in nowadays xbox is obviously doable.
Actually if you need less than 32GB/s and that the bus in the 360 was oversized to take in account the possibly bursty nature of the comunication between shader cores and ROPs that would be a good news (one should not forget either about the communication with the Main RAM). As it is the link in the 360 allow to write to move ~1GB of data per frame (at 33ms a frame) that's a lot more than a handfew of Render target and any sane resolution. Basically you are hold back by the bandwidth to the main RAM (22GB/s).
There are also games that rendered at 1080P on the 360 and the 32 GB/s has not been raised as a concerned as far as I remember.
So at this stage and without insiders giving me clue I start to build the conviction that one may not need that much bandwidth between the shader cores and the ROPs.
In the 360 that bandwidth was also need to move the your render target to the main RAM. If in a hypothetical system the ROPs are on the SoC and render straight into the main RAM bandwidth requirement would be somehow lowered.
In our hypotherical system the link would also be the only way for the GPU to access any kind of data (/texture) so we have to account for that, in the 360 Xenos had only 22GB/s to do so (shared with the CPU). For ref a pci Express x16 link provide up to 32GB/s

To make a long (and iffy) story short I believe that it would be achievable to have a functional second GPU as long as all the ROPs are on the SoC.

I can't see MS shipping being basically a x cores SMP CPUs + a HD 6670. Trying to make sense out of what we heard so far I could see a well design dual graphics solution surprise buy its performances and its silicon footprint.

I will give another try at what could be a really cheap system to produce and would do in fact pretty well as far as performances as concerned (and obviously giving more credibility than needed to all this early talks, but if we learn more I'll try to make sense out of it as anybody else).

SoC
6 tiny and power efficient IO cpu cores 2 or 4 way SMT. Close parent to XENON and POWER A2.
6 SIMD arrays so 96 VLIW5 units or 480 SP (as the hd 6670)
64 Z/Stencil ROP Units & 8 Color ROP Units (twice the hd 6670 so close to the hd 5770)
128-bit GDDR5 memory interface
1200MHz gddr5 => same bandwidth as hd 5770/6770 parts.
UVD3 engine
@ 32nm

GPU 2
"ROP-less" hd 6670, no UVD3 @ 28nm

I won't cone with FLOPS figures or clock speed as it's not reasonable, we've seen that AMD lately use pretty high tensions to make sure all their parts function properly. It could be even worse for a console manufacturers as bad chips have no possible use. The good news for quiet some parts (llano or hd 6670 6570) the difference in GPU clock speed have marginal impact on power consumption. On llano the main offender to power consumption seems to be the CPU cores clock speed, so manufacturers may have more room to play than AMD in the part that interest us the most ie GPU perfs

I believe that the silicon foott print for such a system would be really low, south of 200mm2 for the SOC, around the size of nowadays daughter die for the second GPU.

A summup of the system could be, 6 cores, 960 SP which would sound more sane to a lot of members here. Then it's a matter of clock speed especially the CPU clock speed to make things fit under a single radiator.

[manux]

I wonder if AMD warming up for ARM based designs is due to a console deal?

[liolio]

Hum looking at how console are a tiny part of the whole picture the answer is no.

[east of eastside]

Originally Posted by manux

I wonder if AMD warming up for ARM based designs is due to a console deal?

It's the most business elegant solution. You reduce the design supplier to one (AMD) and the manufacturer to one (Global Foundries).

A six core ARMv8 64 bit MS/AMD custom chip integrated with a high performance AMD GPU in the HSA architecture is the sexiest console design imaginable. The low power ARM cores would allow the power to go the GPU where it will count the most while keeping the CPU allocation of the TDP low.

MS could then turn around and not only run Windows 8, and Windows Phone apps on it, but could reuse the entire IP for other Windows devices.

Given how low performance the PPC GuTS core of XCPU is, emulation of it on the ARMv8 might not be that much of a stretch, while the altivec could be emulated on the GPU.

Do it, MS.

[function]

How are you going to emulate altivec on the GPU with incurring a terrible latency penalty?

[McHuj]

Originally Posted by east of eastside

It's the most business elegant solution. You reduce the design supplier to one (AMD) and the manufacturer to one (Global Foundries).
.

I'm not sure about this. For one, the console maker buys the IP so whether it comes from multiple sources or not, in the end shouldn't matter (of course there could be a better deal by going with one).

I don't think a console manufacturer would want to be limited to one manufacturer. I think you need to be able to move you design between fabs (GF, TSMC, Chartered, IBM, etc) as prices and market demand fluctuates.

But other than that, I don't see a problem with an ARM based CPU provided it can achieve performance equal to a PPC CPU.

[ToTTenTranz]

Originally Posted by east of eastside

It's the most business elegant solution. You reduce the design supplier to one (AMD) and the manufacturer to one (Global Foundries).

A six core ARMv8 64 bit MS/AMD custom chip integrated with a high performance AMD GPU in the HSA architecture is the sexiest console design imaginable. The low power ARM cores would allow the power to go the GPU where it will count the most while keeping the CPU allocation of the TDP low.

MS could then turn around and not only run Windows 8, and Windows Phone apps on it, but could reuse the entire IP for other Windows devices.

Given how low performance the PPC GuTS core of XCPU is, emulation of it on the ARMv8 might not be that much of a stretch, while the altivec could be emulated on the GPU.

Do it, MS.

And why are you assuming an ARM CPU at console TDP levels (+20W?) will perform better than an AMD/Intel/IBM CPU at the same TDP levels?


This myth that ARM will undoubtedly do better than x86/PowerPC at their own game should disappear, at least until there are actually 64bit ARMv8 chips out there.

[hoho]

Originally Posted by ToTTenTranz

This myth that ARM will undoubtedly do better than x86/PowerPC at their own game should disappear, at least until there are actually 64bit ARMv8 chips out there.

Another thing people don't seem to realize is that moving from 32 to 64bits won't change performance at all on it's own. With x86 we got the performance from increased register counts combined with greatly improved architecture (K8). For the ARM to get any performance increase it has to come from other improvements, not just from being able to work on 64bit integers in GP registers.

[east of eastside]

Originally Posted by ToTTenTranz

And why are you assuming an ARM CPU at console TDP levels (+20W?) will perform better than an AMD/Intel/IBM CPU at the same TDP levels?

You're assuming I am. It's not that the ARM CPU will perform better, it is that it will take less of the TDP allowing more of it to be allocated to the performance of the GPU where more of the work is going to be offloaded in the HSA GGPU architecture.

I don't know if things are at the point that the compute clusters on the GPU can start taking over tasks that would have been handled by a powerful CPU in a more traditional design (and handle them more efficiently). That is the question.

This myth that ARM will undoubtedly do better than x86/PowerPC at their own game should disappear, at least until there are actually 64bit ARMv8 chips out there.

I'm not saying that. I'm saying that an ARM based CPU solution will allow an over all more powerful console solution that is more GPU processing centric. If things are at that point yet.. (looking at HSA if that can be implemented in a console.)

If you incorporate a discrete X86/PPC that is $60 of the b.o.m (throwing a number out) and takes 50 to 60 watts of the TDP that all comes out of the cost and resource budget remaining for the discrete GPU and RAM.

If a GPGPU processing model like HSA is possible in time for the next-gen then the lite CPU cores will actually be the way to go, which is what makes ARMv8 and ideal candidate.

If MS doesn't try it, I hope Sony comes up with a tight, integrated GPGPU, SoC based design for PS4. They may end up being close to MS in performance, but beating it in other factors like cost and form factor/size.

[AlphaWolf]

Originally Posted by east of eastside

You're assuming I am. It's not that the ARM CPU will perform better, it is that it will take less of the TDP allowing more of it to be allocated to the performance of the GPU where more of the work is going to be offloaded in the HSA GGPU architecture.

You say you aren't... then outright state that you are assuming that the ARM is better perf/watt.

[east of eastside]

Originally Posted by AlphaWolf

You say you aren't... then outright state that you are assuming that the ARM is better perf/watt.

No, I'm not. Where did I say that? Point it out. I even repeated myself explaining it several times. Jeesus

a discrete ARM CPU is less powerful and lower perf/watt than a discete PPC and X86, okay...

The overall solution (see the difference), using ARM instead of PPC/X86, in a GPGPU console solution where the CPU and GPU are tightly integrated (and the GPU is taking more of the load), like in HSA, you get the better perf/watt.

Another way to state it is this,

I propose that..

A discrete X86/PPC CPU + discrete GPU will be lower perf/watt (in a console with an approx 250watt TDP and $400 retail price)

than...

an integrated ARM CPU + GPU in an HSA GPGPU solution.

This is what I'm referring to when I'm talking about HSA (the next step in CPU-GPU integration), btw:

http://www.bit-tech.net/news/hardwar...roadmap-2013/1

The first Fusion APUs, which combine GPU and CPU technology on a single chip, have been available for some time, but Papermaster's vision goes further. In 2012, he explained, chips will be released that give the GPU access to the CPU memory for increased efficiency and data sharing between the two.

In 2013, this will be further enhanced by doing away with the concept of independent memory altogether. Instead, both the GPU and CPU will share a single unified memory space. The benefit: data can be processed by either subsystem without the delays associated with moving it to different areas of system memory.

Finally, 2014 will see the launch of the first HSA-compatible GPUs. Unlike current general purpose GPU technology, Papermaster claims that the HSA-compatible GPU will be cable of switching its compute context on the fly, executing code on whichever process makes most sense from a performance perspective.

Is HSA a viable solution for next-gen consoles? I don't know, my point is to propose that possibility and discuss it while making the case that ARM would be well suited to it.

The ARM, AMD, MS trifecta may very well factor in the next Xbox. Some early signs point to that direction, though I don't think it is viable for a 2013 release.

[Crossbar]

Originally Posted by AlphaWolf

DDR4 could be a possibility, I believe Samsung started sampling last year.

Indeed, they did. The standard was finalised last fall. But the speed does not reach Gddr5 levels, 2.33 - 3.2 Gbps and only offer 16 bits data bus/module. However, the power draw will be significantly lower as it will beworking at 1.2 V.
Using ddr4 would mean trading speed for larger size. If paired with a framebuffer in edram I think it could be a possible solution.

[AlphaWolf]

Originally Posted by east of eastside

No, I'm not. Where did I say that? Point it out. I even repeated myself explaining it several times. Jeesus

a discrete ARM CPU is less powerful and lower perf/watt than a discete PPC and X86, okay...

The overall solution (see the difference), using ARM instead of PPC/X86, in a GPGPU console solution where the CPU and GPU are tightly integrated (and the GPU is taking more of the load), like in HSA, you get the better perf/watt.

Another way to state it is this,

I propose that..

A discrete X86/PPC CPU + discrete GPU will be lower perf/watt (in a console with an approx 250watt TDP and $400 retail price)

than...

an integrated ARM CPU + GPU in an HSA GPGPU solution.

This is what I'm referring to when I'm talking about HSA (the next step in CPU-GPU integration), btw:

http://www.bit-tech.net/news/hardwar...roadmap-2013/1

Is HSA a viable solution for next-gen consoles? I don't know, my point is to propose that possibility and discuss it while making the case that ARM would be well suited to it.

The ARM, AMD, MS trifecta may very well factor in the next Xbox. Some early signs point to that direction, though I don't think it is viable for a 2013 release.

I still don't see how ARM is offering anything in that scenario. A Jaguar core is probably going to use like 1 watt or something.

Originally Posted by Crossbar

Indeed, they did. The standard was finalised last fall. But the speed does not reach Gddr5 levels, 2.33 - 3.2 Gbps and only offer 16 bits data bus/module. However, the power draw will be significantly lower as it will beworking at 1.2 V.
Using ddr4 would mean trading speed for larger size. If paired with a framebuffer in edram I think it could be a possible solution.

Ya, I was only suggesting it as a possible option to ddr3. Faster, and lower power, but it would likely be insufficient as a sole memory system.

[MrFox]

I thought there was a roadmap for gddr5 to be fully differential, doubling the bandwidth per pin? Is this a reality yet?

[tunafish]

Originally Posted by hoho

Another thing people don't seem to realize is that moving from 32 to 64bits won't change performance at all on it's own. With x86 we got the performance from increased register counts combined with greatly improved architecture (K8). For the ARM to get any performance increase it has to come from other improvements, not just from being able to work on 64bit integers in GP registers.

Note that ARMv8 also doubled registers, to 32. More importantly, they cleared up some of the historical cruft: No more predicates on everything, and shifts baked into instructions are immediate-only.

ARMv8 cpu's should be easier to make fast than older ARM architectures. However, at this point it's unclear how much of the simplification translates into actual usable benefit, given that the actual CPUs will also implement ARMv7 and Thumb-2.

[hoho]

Originally Posted by tunafish

Note that ARMv8 also doubled registers, to 32

Sure but going from 8 (closer to 6 actually usable) to 16 is significantly bigger deal than going from 16 to 32. x86 also doubled the amount of SIMD registers, how about ARMv8?