Support NeoGAF

[Rolf NB]

Extremely? No, more than GC? Yes, but not by much.

If you can barely hit half of your fillrate just drawing flat shaded polygons with zero reserve taken for CPU work or textures, your graphics part is bandwidth starved. Let's not pretend otherwise.

Gamecube had this well covered with eDRAM framebuffer and a gigantic, fast texture cache and texture virtualization.

 

[phosphor112]

If you can barely hit half of your fillrate just drawing flat shaded polygons with zero reserve taken for CPU work or textures, your graphics part is bandwidth starved. Let's not pretend otherwise.

Gamecube had this well covered with eDRAM framebuffer and a gigantic, fast texture cache and texture virtualization.

I uhh... ok.

 

[Thraktor]

I don't really think the polygon performance of GameCube or XBox is relevant here, folks.

 

[lostinblue]

Neither Xbox or Gamecube hit their numbers 100%, but EVEN IF we assume GC hit their numbers 100% because of the fixed functions, it would still be less than Xbox if it was only capable of pushing 60% of those numbers.

That's simplifying it a little too much in a misleading way. Gamecube numbers are not more effective due to it being fixed function; if anything "fixed function T&L" made it so that CPU vertex manipulation had to be used quite often, while you probably never used CPU for vertex/skinning/rigging on Xbox, having not one but two Vertex Shader units.

That's a bottleneck, that Nintendo compensated by using low latency RAM and supporting vertex compression transactions between the CPU and the GPU, to save bandwidth.

And shader model 1.1 wasn't all that programmable either; it just wasn't fixed function in the end, sure; but TEV was manipulable just the same.

And IIRC Xbox didn't do 8 texture layers per pass, those specs are wrong, lots of games did it via the polygon trick, but that's rendering the scene twice.


Anywho and getting back on topic: it's all about efficiency, the less hit doing something the better, but it wasn't strictly about fixed function.

Xbox was supremely bandwidth starved.

It was more a case of being riddled with bottlenecks.

GC's main RAM bandwidth was 2.6 GB/s, against Xbox 6.4 GB/s; memory controllers were 90% and 75% effective, respectively, which means GC could hit 2.34 GB/s throughput and Xbox 4.8 GB/s; that's still half the bandwidth, compensated by the embedded framebuffer, less main RAM latency (30 ns in Xbox and 10 ns on GC) and compression across CPU/GPU communications; embedded texture cache was meant to spam and ease out repetitive tetxures (1 MB of them) hence being used most often for EMBM, fur shading or ground textures; most of the time it gave "bottleneck free effects" (and repetitive texture spamming) more than easing out whatever (because had that not been there they wouldn't even attempt it just like they didn't elsewhere).

Xbox would still have the edge, if the latency wasn't so big and the thing wasn't so bottlenecked.

I don't really think the polygon performance of GameCube or XBox is relevant here, folks.

Indeed it isn't.

 

[Shin Johnpv]

Neither Xbox or Gamecube hit their numbers 100%, but EVEN IF we assume GC hit their numbers 100% because of the fixed functions, it would still be less than Xbox if it was only capable of pushing 60% of those numbers.

I can tell you for a fact that GC with Rogue Squadron II was hitting between 12 - 16 million polys a second, and with RSIII they were doubling that number. Don't forget that, that's with textures, lighting, and other effects going on in those games. The GC exceeded it's on paper performance.

 

[lostinblue]

Although an oficial paper sheet spec, the 6-12 million polygon figure was a conservative number that nintendo thought was attainable and realistic. No such thing as surpassing a theoretical number.

 

[TKM]

But because it's customized it could be as powerful as the customized Liverpool or Cape Verde derivative in XB3?

Customized does not necessarily mean greater performance or feature set. They could have customized it for lower power draw, backwards compatibility, or cost to Nintendo. It may even be slower than the stock arch it's based on.

nVidia took a 7800 and customized for Sony by added Flex IO, a bit more cache, and taking out half the ROPs.

Customization is a meaningless term on its own.

 

[Donnie]

How are you not sure? There is a thing called physics. Something that maxes out at 30 or so watts can't keep up with something that's pushing 100+.

Not that I disagree with your conclusion, but watts isn't a good way to prove it. Look at GC vs XBox or lately WiiU vs 360/PS3

 

[phosphor112]

Not that I disagree with your conclusion, but watts isn't a good way to prove it. Look at GC vs XBox or lately WiiU vs 360/PS3

Well yeah, and compare PS3/360 to Wii U (~70-80 compared to ~30) but PS4/Durango will have so many increases over the Wii U, it is literally impossible for it to compete.

 

[Birdman.]

Regardless, R8xx supports everything newer cards do and it's pretty much the same chip. (well, minus OpenGL 4.3 and other stuff AMD added on the side, some of which Wii U seems to have, like the EyeFinity thing); that's enough to put the R7xx definition in Jeopardy, it's probably closer to an R8xx, perhaps even some R9xx implementations.

EyeFinity is not really a GPU core feature, it's rather related to the display controller logics. R7xx and earlier GPUs also had support for two displays, so that is enough for TV and Wii U controller screen. However, Latte may have custom display controller unlike any PC GPUs because the usage is so different. Anyway, it is also possible that R8xx generation UVD and display controller (like in Llano) are included in Latte with older generation GPU core because those are more or less separate parts.

Thus, I wouldn't even try to identify Latte as R7xx or R8xx implementation based on video decoding of display controller features. The important thing there is whether Latte supports DirectX 11 level features not supported by R700. Both R7xx and R8xx are VLIW5 cores, but the major differences are those between DirectX 10.1 and DirectX 11 feature sets. Remember that R7xx already has tessellation unit (Programmable tessellation unit listed in specs) although not supported by DirectX 10.1, so tessellation support in Latte doesn't mean that it has to be based on R8xx.

 

[blu]

How are you not sure? There is a thing called physics. Something that maxes out at 30 or so watts can't keep up with something that's pushing 100+.

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance. This could turn into an algorithmic advantage of WiiU (and potentially Durango) over Orbis - the low-latency architectures could be able to do things the high-latency one might not.

Just saying.

 

[Pitmonkey]

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance. This could turn into an algorithmic advantage of WiiU (and potentially Durango) over Orbis - the low-latency architectures could be able to do things the high-latency one might not.

Just saying.

Fuckin' Science.

 

[gofreak]

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance.

That's not true, really. From the base architecture (APU) to some lower level details that emerged recently I would hesitate to say PS4 doesn't pay any more attention to CPU/GPU overhead and general memory latency mitigation than a vanilla PC setup.

 

[blu]

That's not true, really. From the base architecture (APU) to some lower level details that emerged recently I would hesitate to say PS4 doesn't pay any more attention to CPU/GPU overhead and latency mitigation than a vanilla PC setup.

Perhaps I'm missing something, but what low-level details emerged recently?

 

[gofreak]

Perhaps I'm missing something, but what low-level details emerged recently?

The ACE thread management changes, for example. I mean with IO stalls, you can mitigate that by reducing wait time on memory (lower latency memory) or by having other work to switch to while you wait. The modifications in PS4's GPU are aimed at substantially improving flexibility and performance around context switching vs ordinary GCN.

 

[lord pie]

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance. This could turn into an algorithmic advantage of WiiU (and potentially Durango) over Orbis - the low-latency architectures could be able to do things the high-latency one might not.

Just saying.

But it's an APU with shared memory, so what would a 'round trip' even be needed for? It isn't like a PC where you have two independent pools of memory with only a slow bus in between (PCIe)... Right?

 

[blu]

The ACE thread management changes, for example. I mean with IO stalls, you can mitigate that by reducing wait time on memory (lower latency memory) or by having other work to switch to while you wait. The modifications in PS4's GPU are aimed at substantially improving flexibility and performance around context switching vs ordinary GCN.

The ACE enhancements are surely addressing the GPU macro-threading abilities (and we can expect so see them in the next crop of AMD GPUs), but they do little for workflows where control flow would ping-pong between the CPU and GPU. Let me elaborate. There are viable workflows where a compute task would be broken down into a series of compute kernels, with CPU traversal & analysis of the intermediate results, before subsequent emits of the next compute kernels and/or draw calls. For the optimal performance (or even viability) of such workflows the one thing that helps the most is a low latency shared pool. An APU with shared GDDR is not the solution - while the GPU can handle the GDDR latencies (read: take the penalties and still yield a net gain), the CPU penalties for such round-trips could void the usefulness of the CPU side in the workflow per se.

 

[gofreak]

The ACE enhancements are surely addressing the GPU macro-threading abilities (and we can expect so see them in the next crop of AMD GPUs), but they do little for workflows where control flow would ping-pong between the CPU and GPU. Let me elaborate. There are viable workflows where a compute task would be broken down into a series of compute kernels, with CPU traversal & analysis of the intermediate results, before subsequent emits of the next compute kernels and/or draw calls. For the optimal performance (or even viability) of such workflows the one thing that helps the most is a low latency shared pool. An APU with shared GDDR is not the solution - while the GPU can handle the GDDR latencies (read: take the penalties and still yield a net gain), the CPU penalties for such round-trips could void the usefulness of the CPU side in the workflow per se.

Oh OK, I was looking more solely at the mitigation of IO stalls rather than inter-chip communication.

However I still think it's a bit of an assumption that PS4's setup is 'PC-like' on that front. Most PCs are not APUs. I do not know the low level details of what's available in PS4's APU, but I wouldn't assume the only communication pipe is that which is pushed through main memory. I believe even in earlier Fusion designs GPU could snoop CPU cache for example. And even the bolt-on RSX in PS3 had facility to communicate on different channels with the CPU. I imagine a single die CPU/GPU combo designed from the ground up has even more goodies on that kind of front, though I don't know what more PS4's may provide beyond earlier APUs. Devs should now have full low-level control over those tools though, whereas earlier on AMD's existing APUs I think some of that capability may have been hidden away behind APIs.

 

[krizzx]

RV8xx is also no more than a linear R7xx revision leaving core structure intact; in past revisions like the Radeon 9500/9700 to the 9600/9800 that would be a small revision of sorts, reflected in the naming changing from R300 to R350 and not a full generation nomenclature. Of course by the time R7xx launched nomenclature didn't work that way anymore, with available cards instead being spanning all over the R7xx numbering logic all up to R790, but point stands.

Regardless, R8xx supports everything newer cards do and it's pretty much the same chip. (well, minus OpenGL 4.3 and other stuff AMD added on the side, some of which Wii U seems to have, like the EyeFinity thing); that's enough to put the R7xx definition in Jeopardy, it's probably closer to an R8xx, perhaps even some R9xx implementations.

Also GCN is at core a R9xx/HD 69xx/VLIW4 evolution.

This is why I'm sticking to the HD5550 theory. The math just matches almost perfectly. its definitely custom built but then you have to take in a degree of reasoning:

1 It matches the theorized numerical performance of Latte almost to perfectly, 2. The tech in it is "cheaper" and has "lower power consumption" than the previous theorized GPU bases, 3. It has better, more efficient multiscreen support. 4. It simply wouldn't make since to tailure and old GPU to run almost exactly like one that already existed.

Is there a die shot of the HD5550 somewhere?

 

[Rolf NB]

I uhh... ok.

Thought so.

 

[lostinblue]

EyeFinity is not really a GPU core feature, it's rather related to the display controller logics. R7xx and earlier GPUs also had support for two displays, so that is enough for TV and Wii U controller screen. However, Latte may have custom display controller unlike any PC GPUs because the usage is so different. Anyway, it is also possible that R8xx generation UVD and display controller (like in Llano) are included in Latte with older generation GPU core because those are more or less separate parts.

Eyefinity is in the spec, unless there was a giant typo never adressed.

Of course, it's a component that you could implement on a stock R700, but then it wouldn't be a R700 anymore, it sure doesn't mess with the core functionality though.

Thus, I wouldn't even try to identify Latte as R7xx or R8xx implementation based on video decoding of display controller features. The important thing there is whether Latte supports DirectX 11 level features not supported by R700. Both R7xx and R8xx are VLIW5 cores, but the major differences are those between DirectX 10.1 and DirectX 11 feature sets. Remember that R7xx already has tessellation unit (Programmable tessellation unit listed in specs) although not supported by DirectX 10.1, so tessellation support in Latte doesn't mean that it has to be based on R8xx.

Me neither, hence I'm really interested in the Tesselation unit to determine the actual core heritage of the product. R8xx Tesselation unit is Generation 3, the one supported by DirectX11, the previous one, the R7xx one is Generation 2. The Generation 3 part is in itself a specific DirectX11 compliant part.

As for R7xx tesselation unit support, I believe it was supported somewhat, after all R600 Tesselation Unit was supported by DirectX 9. And off the top of my head I don't know how different R600 Tesselation Unit is supposed to be next to an R7xx part.

It was usable, but no one did.

Is there a die shot of the HD5550 somewhere?

Not that I know off.

 

[ColdBlooder]

As for R7xx tesselation unit support, I believe it was supported somewhat, after all R600 Tesselation Unit was supported by DirectX 9. And off the top of my head I don't know how different R600 Tesselation Unit is supposed to be next to an R7xx part.

It was usable, but no one did.Not that I know off.

Shin'en comfirmed via Twitter that they will use tesselation in their next Wii U game. We will see how useable Wii Us tesselation unit is soon.

Can't wait to see their next game btw.

 

[Rolf NB]

The ACE enhancements are surely addressing the GPU macro-threading abilities (and we can expect so see them in the next crop of AMD GPUs), but they do little for workflows where control flow would ping-pong between the CPU and GPU. Let me elaborate. There are viable workflows where a compute task would be broken down into a series of compute kernels, with CPU traversal & analysis of the intermediate results, before subsequent emits of the next compute kernels and/or draw calls. For the optimal performance (or even viability) of such workflows the one thing that helps the most is a low latency shared pool. An APU with shared GDDR is not the solution - while the GPU can handle the GDDR latencies (read: take the penalties and still yield a net gain), the CPU penalties for such round-trips could void the usefulness of the CPU side in the workflow per se.

First, it's a shared memory. Data doesn't have to move between CPU and GPU. Both access the same memory.

Second, your fear of "GDDR latency" is based on a fallacy. The mistake comes from measuring latency in clocks, and then ignoring the clock speed. A 20-clock latency at 1GHz is no better or worse than a 10-clock latency at 500MHz. It is exactly the same delay.

 

[tipoo]

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance. This could turn into an algorithmic advantage of WiiU (and potentially Durango) over Orbis - the low-latency architectures could be able to do things the high-latency one might not.

Just saying.

What do you mean? It's an APU with both the CPU and GPU on one die, not just package like the Wii U, with unified memory. The benefit of that is no GPU-CPU memory swaps, they access the same pool. So what round trips are you talking about? If anything the APU would have even better data sharing than the package.

Edit: Saw your clarification, so it's the GDDR5 latency affecting the CPU you're worried about, not GPU-CPU memory swapping? GDDR5 does have a higher latency - at the same clock speed - but we're talking about a 5.5GHz effective rate here, plus modern CPUs only take a few percent hit with the biggest possible latency deltas with current DDR5. The GDDR5 may have an even bigger delta than the fastest-slowest DDR3, but I think the shared pool will be a worthwhile tradeoff for the presumably small performance hit the CPU will take for that.

And I'm quite sure that the CPU speed difference will still be far in excess of what the GDDR5 will shave off in relation to the DDR3 in the Wii U.

 

[ColdBlooder]

With the PS4 announced now, a PS4 spec thread should be possible to make...

Just a hint

Do we have a clue what Takeda meant with "Memory intensified design"?

 

[Zoramon089]

With the PS4 announced now, a PS4 spec thread should be possible to make...

Just a hint

Do we have a clue what Takeda meant with "Memory intensified design"?

I'm assuming he meant the fact that there's the huge eDRAM and a number of other small memory pools

 

[tkscz]

I was only suggesting that the original base is related to VLIW, which I'd say by its documentation provided by Nintendo is likely (it was a copy+paste job, almost). Not that it isn't a custom chip. Looking at the die shots proves it's not anything near a vanilla R7xx.

As far as detailing the architecture - the pre-launch spec sheet that was leaked didn't even go deep enough to mention anything specific about performance, let alone architecture. lol

Looking at the chip magnified, it's clear it's been modified by the engineers responsible.

Correct me if I'm wrong, but wasn't that spec sheet for the prototype dev kits?

 

[krizzx]

Correct me if I'm wrong, but wasn't that spec sheet for the prototype dev kits?

I'm pretty sure it was as well. There have been many changes made since the prototypes days. Like how the original Wii U gamepad had sliders instead of analogs and how they still used the Wii Classic Controller Pro back then.

Also, I wonder why no one uses the garden tech demo for analysis. http://www.youtube.com/watch?v=6OHUwDShrD4 I notice that the water in this looks just like the water in Monoliths X

 

[lostinblue]

Also, I wonder why no one uses the garden tech demo for analysis. http://www.youtube.com/watch?v=6OHUwDShrD4 I notice that the water in this looks just like the water in Monoliths X

Nintendo should put that shit on the store, along with the Zelda tech demo; sure some fiddling might be needed since it was running on unfinished hardware but I'll be dammed.

You know, hold the fort and serve as an example of what the console can do on-spec.

 

[blu]

First, it's a shared memory. Data doesn't have to move between CPU and GPU. Both access the same memory.

Most bus masters in a system 'access the same memory' with the CPU. You entirely missed the.. oh, wait, you didn't! Let's see:

Second, your fear of "GDDR latency" is based on a fallacy. The mistake comes from measuring latency in clocks, and then ignoring the clock speed. A 20-clock latency at 1GHz is no better or worse than a 10-clock latency at 500MHz. It is exactly the same delay.

My "fear" that GDDR latency would be orders of magnitude greater than what could be effectively L3 to the CPU? I guess I'm easily frightened like that.

What do you mean? It's an APU with both the CPU and GPU on one die, not just package like the Wii U, with unified memory. The benefit of that is no GPU-CPU memory swaps, they access the same pool. So what round trips are you talking about? If anything the APU would have even better data sharing than the package.

Edit: Saw your clarification, so it's the GDDR5 latency affecting the CPU you're worried about, not GPU-CPU memory swapping? GDDR5 does have a higher latency - at the same clock speed - but we're talking about a 5.5GHz effective rate here, plus modern CPUs only take a few percent hit with the biggest possible latency deltas with current DDR5. The GDDR5 may have an even bigger delta than the fastest-slowest DDR3, but I think the shared pool will be a worthwhile tradeoff for the presumably small performance hit the CPU will take for that.

And I'm quite sure that the CPU speed difference will still be far in excess of what the GDDR5 will shave off in relation to the DDR3 in the Wii U.

I'm not comparing latencies between DDR3 and GDDR5 (I'm assuming you meant to say DDR3, otherwise I have no idea what you're referring to). I'm comparing latencies between GDDR5 and ram embedded in what is, for all intents and purposes, the memory controller. We're talking hundreds of cycles (typical DDR3 latency at a L3 miss, TLB misses non-withstanding (though they normally go hand-in-hand for fully-random access)) vs tens of cycles (typical L3 latency), OIOW differences which we generally refer to as 'orders of magnitude'. Also, the DDR IO effective rate is a throughput thing with little relevance to the random-access latencies of the individual bank in an xDDRn setup.

 

[tipoo]

I'm not comparing latencies between DDR3 and GDDR5 (I'm assuming you meant to say DDR3, otherwise I have no idea what you're referring to). I'm comparing latencies between GDDR5 and ram embedded in what is, for all intents and purposes, the memory controller. We're talking hundreds of cycles (typical DDR3 latency at a L3 miss, TLB misses non-withstanding (though they normally go hand-in-hand for fully-random access)) vs tens of cycles (typical L3 latency), OIOW differences which we generally refer to as 'orders of magnitude'. Also, the DDR IO effective rate is a throughput thing with little relevance to the random-access latencies of the individual bank in an xDDRn setup.

Ah, ok.

What about the 4MB L2 cache sitting on the same die as the GPU in the PS4 and presumably Durango though? APU solutions already let the GPU access the cache on PCs, I would think that would be high priority on the consoles too.

You could then say the Wii U has more of it at 32MB, but that's also making up for the lack of bandwidth to the main memory for the GPU, I would wager a lot of it will be used up that way.

And in terms of the Durango it is also rumored to have embedded RAM on the GPU to make up for main memory bandwidth much like the Wii U, in that case there is no talking point at all for the Wii U since that theory would have to reflect on both of them.

I'm not comparing latencies between DDR3 and GDDR5 (I'm assuming you meant to say DDR3, otherwise I have no idea what you're referring to).

Where did I use the wrong one?

 

[JohnnySasaki86]

Throughput is only one side of the coin. Another is latencies. While we don't know much about Durango's edram setup (CPU access, etc), the current picture of Orbis indicates it's very PC-like in its reliance on sheer BW, while it does nothing to address the CPU-GPU round-trip latencies, for instance. This could turn into an algorithmic advantage of WiiU (and potentially Durango) over Orbis - the low-latency architectures could be able to do things the high-latency one might not.

Just saying.

Orbis is an APU though. I thought this was one of the performance advantages of an APU set up. Much lower latencies.

Edit: Wii U doesn't gain the same performance advantages through a MCM. I've also read that in PC's, APU's haven't been properly taken advantage of yet. In a closed console environment we'll finally see what there capable of.

You might be right. I thought I read it was 8XXX, though.



We don't? I thought everyone basically confirmed it was from the 4XXX series?

PS4's GPU indeed may have more in common with 8xxx, because the compute modifications may indeed be a custom version of there GCN 2.0 architecture in the upcoming 8xxx.

 

[ozfunghi]

Anyway, the other 2 tech threads have come to a complete halt. Is there anything we could still find out about Espresso from the x-rays, or is that basically a finished chapter until new leaks? Or can we expect something out of the hacking community? I don't expect Blu to be able to do his benchmark on WIiU anytime soon

Nope.

Rebel Strike begs to differ.

 

[tipoo]

Anyway, the other 2 tech threads have come to a complete halt. Is there anything we could still find out about Espresso from the x-rays, or is that basically a finished chapter until new leaks? Or can we expect something out of the hacking community? I don't expect Blu to be able to do his benchmark on WIiU anytime soon

I think we're pretty much down to bickering about micro-wins and losses, at least until hackers have more going on the Wii U. Even then we may never know, as they can get to the exploit stage without really understanding everything behind it. The overall picture is mostly colored in I think.

 

[MDX]

Why did Nintendo go with the MCM instead of an APU?

 

[Effect]

Nintendo should put that shit on the store, along with the Zelda tech demo; sure some fiddling might be needed since it was running on unfinished hardware but I'll be dammed.

You know, hold the fort and serve as an example of what the console can do on-spec.

That would be great if they did. I've always wanted to see a direct feed version of it just to have been able to see it for myself. The other Nintendo Direct videos are on the eShop. One just has to search for only videos on the Wii U and you can find the Monolith Soft game trailer and other ones if anyone is interested. They weren't taken down.

 

[Spongebob]

Why did Nintendo go with the MCM instead of an APU?

Isn't the CPU 45nm and the GPU 40nm?

 

[antonz]

Why did Nintendo go with the MCM instead of an APU?

Backwards compatibility foced a lot of their decisions with the CPU. They were not willing to kill off Wii software playability. Its an interesting road they are going to face for their next console. Do they stay with IBM again and shift to a new PowerPC or will they end up following MS and Sony to the land of PC.

Nintendo in one of the Iwata asks I believe went into other reasons for the MCM.

 

[lostinblue]

^ It's simple, really.

Putting IBM and AMD working together and exchanging trade secrets between them for integrated design was a no go, just like it wasn't for XCGPU previously, hence they have to remain separate.

That would be like AMD and Nvidia working together or something, or permiting any of them to do or suggest changes to the architectures at place, and they don't want each other to go anywhere near their turf.

 

[Oblivion]

Apologies for asking this again, but I never got an answer: Was the Zelda demo 60 fps?

 

[krizzx]

Apologies for asking this again, but I never got an answer: Was the Zelda demo 60 fps?

Yes.

 

[MDX]

Iwata:

Due to this MCM, the package costs less and we could speed up data exchange among two LSIs while lowering power consumption. And also the international division of labor in general, would be cost-effective.

Backwards compatibility foced a lot of their decisions with the CPU. ]

Backwards compatibility, good point.

^ It's simple, really.

Putting IBM and AMD working together and exchanging trade secrets between them for integrated design was a no go,

Trade secrets, good point.

What about Nintendo's long standing (Billion$) deal with IBM? How many consoles or years was that supposed to cover? Because it did cover more than the Gamecube. Also, what about wanting a more powerful GPU that could be found outside of an APU? Technically, Nintendo could have gone with a CPU + APU design.

 

[Baki]

Why such a crazy custom job? Also $100 chip sounds close to the pS4 APU projected price.

 

[tipoo]

Why such a crazy custom job? Also $100 chip sounds close to the pS4 APU projected price.

Not a chance. The PS4 APU is the most powerful APU AMD has ever made by far, and some APUs cost over 100 already. Even taking out AMDs profit margin (which is thin to start with), I doubt that.


http://www.tigerdirect.ca/applications/category/category_slc.asp?CatId=7182&name=AMD-APUs&

 

[Oblivion]

Yes.

Is there confirmation anywhere?

 

[A More Normal Bird]

Also, what about wanting a more powerful GPU that could be found outside of an APU?

I may be misinterpreting here, but are you suggesting this as a reason for using an MCM in the Wii U?

 

[ColdBlooder]

Not a chance. The PS4 APU is the most powerful APU AMD has ever made by far, and some APUs cost over 100 already. Even taking out AMDs profit margin (which is thin to start with), I doubt that.


http://www.tigerdirect.ca/applications/category/category_slc.asp?CatId=7182&name=AMD-APUs&

Thats just wrong. Trinity APUs run circles around PS4 cpu. PS4s CPU is a Tablet/Netook apus. Trinity CPU cores are much stronger.

 

[tipoo]

Thats just wrong. Trinity APUs run circles around PS4 cpu. PS4s CPU is a Tablet/Netook apus. Trinity CPU cores are much stronger.

I mean none of them pack anything close to 7850-like power on an APU, and that takes more die size than the bigger CPU cores would. Unlikely it costs under 100.

 

[ColdBlooder]

I mean none of them pack anything close to 7850-like power on an APU, and that takes more die size than the bigger CPU cores would. Unlikely it costs under 100.

Should have said "Most powerful GPU core in an APU" though since CPUs in current PC APUs is still the most prominent part.

PS4s APU (GPU focus) is basically a reverse Desktop APU (CPU focus) in design

 

[i-Lo]

Looks like StevieP is on the money.

Iwata:





Backwards compatibility, good point.




Trade secrets, good point.

What about Nintendo's long standing (Billion$) deal with IBM? How many consoles or years was that supposed to cover? Because it did cover more than the Gamecube. Also, what about wanting a more powerful GPU that could be found outside of an APU? Technically, Nintendo could have gone with a CPU + APU design.

Forgive oh great one, I tried to show them the error of their ways but none would concede that WiiU's GPU would outdo PS4/XB3's GPU in lighting and DoF. Forgive these poor souls for they do not possess your insider knowledge and wisdom to know that WiiU's Latte merely plays possum to hoodwink the competitors and at heart it is an unrivalled beast. Their lies will not sway me from the path of truth; WiiU's GPU by your words would not only compete with DX11 (and equivalent) GPUs but best them in the holy grail towards achieving realism, lighting.

Spoiler

/jk