Support NeoGAF

[Fourth Storm]

Your assumptions here are a bit off. The wattage of a 160ALU @ 550 MHz on 40nm that is designed in a bubble, would be ~10watts, not to mention it is MCM and low powered 40nm process being extremely likely.

Another problem is the document, final hardware didn't exist for launch, in order to make the launch games, stand in hardware needed to be used. Wii U's dev kits from early on were R700 this made sense to continue to code around, these games were "designed in a bubble" meaning that the code they wrote would have to work on the dev kits that existed at the time, VLIW5 code works beautifully on VLIW4 and even better on GCN. If you want to test this, pull a VLIW5 designed demo and run it on the newer card, even at the same specs, it will run better on the later designs, your assumptions here are misguided and they don't fit with the reality we see in the die photo.

Did you take a look at the GCN memory set up? I think the major problem with using R700 as the final specs is that that document was written for the dev kits received, I talked to a source around that time and he had mentioned that the document kept being updated. This points to a changing environment, I haven't had the chance to speak to him since September but it is likely that in November final hardware no longer resembled what was in the dev kit. could also be a strong reason why NFS was so easily impressive, while launch software failed to do anything beyond last gen consoles, the dev kits were simply not close enough to final hardware.

PS that would also explain the fps drops we see in COD BOP2.

From what I've read, the main advantage of VLIW4 vs VLIW5 is that VLIW4 simply allowed them to fit more shader cores on the design. A low SPU VLIW4 design should not have any great advantage over VLIW5. VLIW5 also has a greater theoretical performance. There is a reason AMD went back to it before finally switching to GCN.

Devs working on PC games would have a more difficult time optimizing for VLIW5 because they are likely working through DirectX and have to ensure the code runs on a variety of cards from both AMD and NVidia. If early on Wii U games were optimized to actually keep all 5 ALUs in the VLIW5 fed (which is certainly possible considering ports were likely already optimized for the vec4+scalar config of the 360), a switch to VLIW4 could really throw a monkey wrench into that code, unless the shader count was jacked up.

Edit: As for a GCN setup, that would look much much different than what we are seeing on Latte. The SRAM amount in the compute units, for one, would be significantly higher.

 

[frankie_baby]

From what I've read, the main advantage of VLIW4 vs VLIW5 is that VLIW4 simply allowed them to fit more shader cores on the design. A low SPU VLIW4 design should not have any great advantage over VLIW5. VLIW5 also has a greater theoretical performance. There is a reason AMD went back to it before finally switching to GCN.

Devs working on PC games would have a more difficult time optimizing for VLIW5 because they are likely working through DirectX and have to ensure the code runs on a variety of cards from both AMD and NVidia. If early on Wii U games were optimized to actually keep all 5 ALUs in the VLIW5 fed (which is certainly possible considering ports were likely already optimized for the vec4+scalar config of the 360), a switch to VLIW4 could really throw a monkey wrench into that code, unless the shader count was jacked up.

well there was a dev kit revision that broke code compatibility

 

[Fourth Storm]

No ROPs whatsoever? ; )

Ha, I didn't think they often presented a bottleneck when it comes to sheer resolution, unless we were talking significant amounts of AA/post processing effects. I mean, the 360/PS3 have 8 ROPs and can run games up to 1080p under the right conditions.

well there was a dev kit revision that broke code compatibility

I believe that was when they switched compilers, probably because the Green Hills one they now use does a better job of optimizing code and extracting instruction level parallelism, thus increasing overall performance. If Wii U was safely stronger than the current gen consoles, this licensing of expensive Green Hills software probably wouldn't have even been necessary.

 

[Schnozberry]

well there was a dev kit revision that broke code compatibility

Was there a GAF thread about this? Or a link somewhere?

 

[frankie_baby]

Was there a GAF thread about this? Or a link somewhere?

it was somewhere in one of the many speculation threads

 

[The Abominable Snowman]

Wait, are we back to "Shoddy ports" now rather than "underperforming hardware"?

These threads go in cycles.

Anything that even remotely sounds like something negative towards the hardware gets thrown back as being the fault of someone else other than AMD/Nintendo. Its a one-sided discussion. Everything that is slightly pessimistic is generally thrown out by the most active posters. Selective memories, and all that.

In reality we would see superfluous improvements in certain aspects of the games, like we have with NFSMW and its taking advantage of the more recent feature set and RAM in the Wii U.

 

[Schnozberry]

From what I've read, the main advantage of VLIW4 vs VLIW5 is that VLIW4 simply allowed them to fit more shader cores on the design. A low SPU VLIW4 design should not have any great advantage over VLIW5. VLIW5 also has a greater theoretical performance. There is a reason AMD went back to it before finally switching to GCN.

Devs working on PC games would have a more difficult time optimizing for VLIW5 because they are likely working through DirectX and have to ensure the code runs on a variety of cards from both AMD and NVidia. If early on Wii U games were optimized to actually keep all 5 ALUs in the VLIW5 fed (which is certainly possible considering ports were likely already optimized for the vec4+scalar config of the 360), a switch to VLIW4 could really throw a monkey wrench into that code, unless the shader count was jacked up.

The other advantage of VLIW4 is more efficient utilization. On average, AMD's best VLIW5 design was 60-80% efficient, because in a lot of cases instructions were not using the fifth SP in a cluster. VLIW5 is is heavily reliant on instruction level parallelism, and unfortunately in normal usage situations it left a lot of unused SP's. That's why VLIW4 and now GCN are geared more towards thread level parallelism, which is closer to NVIDIA's approach that was able to produce similar performance to AMD with far less stream processors. VLIW5 has a much higher performance ceiling at maximum utilization, but the reason AMD went away from it is because it was hard to find situations where that was taking place.

 

[OG_Original Gamer]

Highly customized part, that can be diagnosed using common parts!

 

[blu]

Ha, I didn't think they often presented a bottleneck when it comes to sheer resolution, unless we were talking significant amounts of AA/post processing effects. I mean, the 360/PS3 have 8 ROPs and can run games up to 1080p under the right conditions.

ROPs matter in any ALU-light scenario - e.g. zexel-heavy scenarios (depth textures for shadows), lush particle scenes with lots of overdraw (explosions, smoke, fumes, blizzard, etc), volumetric effects (fog, mist, godrays, etc), as well as large-estate plain-texture scenarios (fancy GUI effects are prime examples of that). Otherwise you can create a 1080p game with one ROP@500MHz, when the game was designed from the start with that condition in mind.

 

[Schnozberry]

it was somewhere in one of the many speculation threads

I was able to find the posts in a search, and it looks like it was initially posted by wsippel. We'll see if he is lurking around here to give us an idea if he got any more information about what caused the broken code problems. It looks like they switched compilers, but nobody ever posted any detailed information as to why. Could have been just API changes, or it could have been a hardware revision that necessitated the change.

 

[Fourth Storm]

The other advantage of VLIW4 is more efficient utilization. On average, AMD's best VLIW5 design was 60-80% efficient, because in a lot of cases instructions were not using the fifth SPU in a cluster. VLIW5 is is heavily reliant on instruction level parallelism, and unfortunately in normal usage situations it left a lot of unused SP's. That's why VLIW4 and now GCN are geared more towards thread level parallelism, which is closer to NVIDIA's approach that was able to produce similar performance to AMD with far less stream processors. VLIW5 has a much higher performance ceiling at maximum utilization, but the reason AMD went away from it is because it was hard to find situations where that was taking place.

You are correct. VLIW4 is more efficient overall because of the difficulty in keeping all 5 ALUs in the VLIW5 processor constantly fed. Again though, we are talking about PC games which are not exactly coded "to the metal." haha. I'm just guessing now, but it seems code optimized for 360's architecture would run easier on VLIW5. Plus, the switch to an expensive compiler seems to hint at a need for more ILP.

Edit: The efficiency/more ALU advantage of VLIW4 goes hand in hand. Since AMD concluded that the fifth ALU in the SP block was being underutilized, they cut it out of VLIW4. This, in turn, makes the architecture "more efficient" and also saves space for adding more SP blocks total.

 

[Easy_D]

I don't even think you can call them shoddy ports. More like shoddy tools that forced the hands of developers to release poorly optimized ports.

Also, the hardware is what it is. Fourth Storm has the strongest theory about what it is right now, and it puts it in line or perhaps slightly stronger than current gen (depending on efficiency) with much more modern feature support.

So basically, the PSP->3DS = 360->WiiU? Not much more "raw power" but some more modern features that will allow games to have a visible edge?

Except that the 3DS's Pica-200 is better documented and easier to implement effects I guess?

 

[Scrawnton]

No aspects about that sound like pr. It sounds like a professional dev analysis and recap of experiences with development on the hardware.

Why do people spin all positive/progressive comments about the Wii U as pr talk? Devs claim the Wii U has DX11 shading capabilities ="Oh, thats just pr talk". Yet if someone says something negative about the Wii U hardware they take it at face value as absolute 100% fact without questioning it and spread it to everyone corner of the internet they can find like with the recent comments from Insomniac and about the Frostbite engine.

When I'm at work reading neogaf, I hate Nintendo for the Wii u. When I am at home playing my wii u, I am in so much love with it. Love the os, the feel, the games, the everything.

Wii not being in HD is not why I felt off playing Wii games. It was the lack of a positive community. Now I can play Nintendo games on an always connected system with other Nintendo fans. That's why I love the Wii u , not that it has a slow CPU or hard to develop for gpu.

From what I gathered off reading neogaf, a lot of people want to see Nintendo drown and they are dismissing good news and spreading bad news even if the bad news is a flat out lie.

 

[Hermii]

When I'm at work reading neogaf, I hate Nintendo for the Wii u. When I am at home playing my wii u, I am in so much love with it. Love the os, the feel, the games, the everything.

Wii not being in HD is not why I felt off playing Wii games. It was the lack of a positive community. Now I can play Nintendo games on an always connected system with other Nintendo fans. That's why I love the Wii u , not that it has a slow CPU or hard to develop for gpu.

From what I gathered off reading neogaf, a lot of people want to see Nintendo drown and they are dismissing good news and spreading bad news even if the bad news is a flat out lie.

Thats PR talk right there !

 

[prag16]

When I'm at work reading neogaf, I hate Nintendo for the Wii u. When I am at home playing my wii u, I am in so much love with it. Love the os, the feel, the games, the everything.

Wii not being in HD is not why I felt off playing Wii games. It was the lack of a positive community. Now I can play Nintendo games on an always connected system with other Nintendo fans. That's why I love the Wii u , not that it has a slow CPU or hard to develop for gpu.

From what I gathered off reading neogaf, a lot of people want to see Nintendo drown and they are dismissing good news and spreading bad news even if the bad news is a flat out lie.

Heh interesting comment, and I agree to a point.

Reading gaf at work can be depressing with regard to the Wii U. But when I'm actually at home playing it, I experience no such depression. xD

 

[Scrawnton]

Thats PR talk right there !

I can't wait for my Nintendo check to come in the mail, then.

 

[chaosblade]

You are correct. VLIW4 is more efficient overall because of the difficulty in keeping all 5 ALUs in the VLIW5 processor constantly fed. Again though, we are talking about PC games which are not exactly coded "to the metal." haha. I'm just guessing now, but it seems code optimized for 360's architecture would run easier on VLIW5. Plus, the switch to an expensive compiler seems to hint at a need for more ILP.

This was something I asked about before, and the impression I ended up with is that even when compiling for a VLIW5 GPU specifically, you're still going to have many, many situations where you won't be able to run it at maximum capacity. But I've never programmed to at level before, so I'm basically just going off what I read on the Internet. And you know what they say about believing everything you read on the Internet.

 

[Schnozberry]

You are correct. VLIW4 is more efficient overall because of the difficulty in keeping all 5 ALUs in the VLIW5 processor constantly fed. Again though, we are talking about PC games which are not exactly coded "to the metal." haha. I'm just guessing now, but it seems code optimized for 360's architecture would run easier on VLIW5. Plus, the switch to an expensive compiler seems to hint at a need for more ILP.

This is no judgment on you or your very competent analysis, but I really wish we had better answers for this stuff.

 

[sfried]

From what I gathered off reading neogaf, a lot of people want to see Nintendo drown and they are dismissing good news and spreading bad news even if the bad news is a flat out lie.

I actually wanted to point out that awhile back, there was a fair bit of balance in views but, as of late, things seem to be tumbling down and going with the bandwagon that it's good to dismiss Nintendo as incompeten,t enough for them to go 3rd party, etc.

I mean, unnecessariy ranting threads just seem to pop-up (and coincided) with the rise of PS4 and New XB news. I could already predict a "Who's going to seel their Nintendo consoles for Sony's/Microsoft's offerings" thread being posted in the near future. GAF love munching on hyperboles and hype.

 

[Schnozberry]

I actually wanted to point out that awhile back, there was a fair bit of balance in views but, as of late, things seem to be tumbling down and going with the bandwagon that it's good to dismiss Nintendo as incompeten,t enough for them to go 3rd party, etc.

I mean, unnecessariy ranting threads just seem to pop-up (and coincided) with the rise of PS4 and New XB news. I could already predict a "Who's going to seel their Nintendo consoles for Sony's/Microsoft's offerings" thread being posted in the near future. GAF love munching on hyperboles and hype.

In regards to Nintendo hardware, people are always victims of their own expectations.

Nintendo botched the living shit out of the launch, and so they deserve some scorn, but GAF is determined to find a new and inventive ways to beat that dead horse every day.

 

[krizzx]

Wait, are we back to "Shoddy ports" now rather than "underperforming hardware"?

No, just one. Its not plural. The Darksiders port is undeniably bad in all aspects. Someone tried to use it to make a claim that the Wii U required geometry to be down scaled despite it being opposite case in any game that had effort invested.

So basically, the PSP->3DS = 360->WiiU? Not much more "raw power" but some more modern features that will allow games to have a visible edge?

Except that the 3DS's Pica-200 is better documented and easier to implement effects I guess?

I'm pretty sure the 3DS has a LOT more power than the PSP all around as the 3DS is more powerful than the PS2.

http://www.youtube.com/watch?v=MgsXOexnOes
http://www.youtube.com/watch?v=rdA_l5FSS18

 

[Fourth Storm]

ROPs matter in any ALU-light scenario - e.g. zexel-heavy scenarios (depth textures for shadows), lush particle scenes with lots of overdraw (explosions, smoke, fumes, blizzard, etc), volumetric effects (fog, mist, godrays, etc), as well as large-estate plain-texture scenarios (fancy GUI effects are prime examples of that). Otherwise you can create a 1080p game with one ROP@500MHz, when the game was designed from the start with that condition in mind.

lol at that last scenario. Thanks, that makes sense. I did also know about their role in alpha blending, but ROPs do still confound me to some degree.

This is no judgment on you or your very competent analysis, but I really wish we had better answers for this stuff.

If Homebrew picks up, we might get them someday. Or maybe some indie dev will leak something. Oh, and just in case you didn't see, I made a small addition to that last post.

 

[Hermii]

I feel like this Miyamoto quote from 2011 summarizes all the tech discussions.

"We're very sensitive, of course, to trying to do all of this at an appropriate price. So I don't know that we would be able to sit here and say that it's going to necessarily dramatically outperform the systems that are out now. It's part of the balance that we strike in terms of trying to find entertainment that is new and unique."

 

[z0m3le]

From what I've read, the main advantage of VLIW4 vs VLIW5 is that VLIW4 simply allowed them to fit more shader cores on the design. A low SPU VLIW4 design should not have any great advantage over VLIW5. VLIW5 also has a greater theoretical performance. There is a reason AMD went back to it before finally switching to GCN.

Devs working on PC games would have a more difficult time optimizing for VLIW5 because they are likely working through DirectX and have to ensure the code runs on a variety of cards from both AMD and NVidia. If early on Wii U games were optimized to actually keep all 5 ALUs in the VLIW5 fed (which is certainly possible considering ports were likely already optimized for the vec4+scalar config of the 360), a switch to VLIW4 could really throw a monkey wrench into that code, unless the shader count was jacked up.

Edit: As for a GCN setup, that would look much much different than what we are seeing on Latte. The SRAM amount in the compute units, for one, would be significantly higher.

Actually as the link I posted earlier mentioned, ALUs from the gcn use less sram thank vliw5 or 4, also the reason vliw5 was rarely using the 5th shader was because it was a specialized shader, moving to vliw4 allowed all sharers to handle the larger tasks usually left to the 5th shader of vliw5. The gpu is very custom, SRAM matches up with gcn in a 32 alu cluster per spu. I am not assuming this has become gcn mind you, just that it isn't vliw5 and while the dev kits early on where r700, all of our information now points to final hardware not going out to developers until launch month after some or even all of the launch titles went gold.

launch titles therefore are a horrible indicator of the hardware, this likely isn't r700 because that hardware AMD could of had finished at a much earlier stage, my insider wasn't just anyone and he has been confirmed by others, his only addition to my analyst though is that Wii u hardware kept changing right up to and including final hardware, the dev kit documents he was given also changed along the way to include new features.

 

[Schnozberry]

Edit: The efficiency/more ALU advantage of VLIW4 goes hand in hand. Since AMD concluded that the fifth ALU in the SP block was being underutilized, they cut it out of VLIW4. This, in turn, makes the architecture "more efficient" and also saves space for adding more SP blocks total.

Yeah, they cut out the scalar unit and left the four vector units, and the memory configuration was left pretty much the same. That's why I thought we might have more than 160SP's with the same memory configuration under a VLIW4 scenario.

Here's a decent PDF diagram I found that gives a basic overview of the differences between VLIW4, VLIW5, and GCN SIMD engine layouts. You may already know this, but it may help others understand.

http://pc.watch.impress.co.jp/video/pcw/docs/592/131/p17.pdf

 

[Fourth Storm]

Actually as the link I posted earlier mentioned, ALUs from the gcn use less sram thank vliw5 or 4, also the reason vliw5 was rarely using the 5th shader was because it was a specialized shader, moving to vliw4 allowed all sharers to handle the larger tasks usually left to the 5th shader of vliw5. The gpu is very custom, SRAM matches up with gcn in a 32 alu cluster per spu. I am not assuming this has become gcn mind you, just that it isn't vliw5 and while the dev kits early on where r700, all of our information now points to final hardware not going out to developers until launch month after some or even all of the launch titles went gold.

In GCN, the SIMD-16 vector units have 64kB of register space. Latte simply shares nothing in common with GCN whatsoever. The thing has a friggin 2010 copyright on it! Dev kits were changing up to launch, I am sure (and likely are still changing even now), but that was likely a combination of API tweaks and clock speed upgrades.

 

[Schnozberry]

In GCN, the SIMD-16 vector units have 64kB of register space. Latte simply shares nothing in common with GCN whatsoever. The thing has a friggin 2010 copyright on it! Dev kits were changing up to launch, I am sure (and likely are still changing even now), but that was likely a combination of API tweaks and clock speed upgrades.

Yeah, GCN doesn't appear to be possible with the memory configuration. To be fair, though, my Intel Q6600 has a copyright of 2005 on it even though it didn't release until January 07. I don't think the copyright is necessarily a reason to rule it out.

 

[freezamite]

Power consumption is another strong indication, yes. As is fuction's observation on beyond3D that we would at least be seeing 720p resolution as standard if Latte had a shader advantage over Xenos/RSX. Yet, games like Sonic Racers, BLOPS2, and Tekken sacrifice resolution just like the other console versions. On a 320 shader machine, that would not be necessary, as resolution is pretty much entirely dependent on GPU strength.

This means nothing in a console like the WiiU. More resolution also means bigger buffers, and in a PC where even the lowest end cards have 1GB of VRAM with high enough bandwidth to reach the 1080p milestone without being bottlenecked by the memory a better GPU automatically means better framerate or better resolution.

But in WiiU the memory subsystem is entirely different. You have a big pool of RAM that is in fact slower than the main pool of RAM on the Xbox 360, but in order to compensate that, it has much bigger caches. If a game on the Xbox 360 has to (for example) perform some sort of tiling or operations or something that requires to read from the eDram (and to do that, the data had to be written to the main RAM and then sent to the GPU because reading from the eDram was impossible on the Xbox360) then if not reprogrammed to this new architecture, those functions will face a bottleneck on the main RAM memory because it has a lower bandwidth than the Xbox 360 main pool of RAM.

It just wouldn't make sense for Nintendo to document the chip as being based on R700 in the leaked feature sheet (which has been confirmed by insiders) and then change it to something else entirely. Going from VLIW5 to VLIW4 or GCN would require devs to do major code revisions in order to optimize for those architectures.

The shader blocks themselves also look pretty similar to those of RV770, even though the layout of the chip as a whole is pretty different. Same goes for the T blocks, which I identify as TMUs. They look alot like those on the RV770.

While it's true that they won't be much different than what we found on the R700, it's perfectly possible that they could have some extra functions or some functions ripped out and double the ALUs per block.
There is certainly something more there than 20 normal R700 ALUs, and since some functions on those ALUs were aimed at decoding some video formats and some other functions that may be useless in a videogame, I wouldn't find it strange to have more ALUs than the standard design.

 

[AzaK]

But in WiiU the memory subsystem is entirely different. You have a big pool of RAM that is in fact slower than the main pool of RAM on the Xbox 360, but in order to compensate that, it has much bigger caches. If a game on the Xbox 360 has to (for example) perform some sort of tiling or operations or something that requires to read from the eDram (and to do that, the data had to be written to the main RAM and then sent to the GPU because reading from the eDram was impossible on the Xbox360) then if not reprogrammed to this new architecture, those functions will face a bottleneck on the main RAM memory because it has a lower bandwidth than the Xbox 360 main pool of RAM.
.

I've wondered this out loud many times. If those engines were not reworked enough to use the memory layout as it could be used on Wii U (Different to 360) then all these ports could very well be suffering from inefficient memory usage. i.e. Too many writes/reads to main RAM. However I'm not sure of the effort required to rework to use quantity-restricted eDRAM on the Wii U as it's intended; it could be trivial in a well written engine.

 

[Schnozberry]

I've wondered this out loud many times. If those engines were not reworked enough to use the memory layout as it could be used on Wii U (Different to 360) then all these ports could very well be suffering from inefficient memory usage. i.e. Too many writes/reads to main RAM. However I'm not sure of the effort required to rework to use quantity-restricted eDRAM on the Wii U as it's intended; it could be trivial in a well written engine.

If all the caches and EDRAM are used effectively, the machine shouldn't be bandwidth starved. Performance penalties would be pretty severe if you are constantly reading and writing from main memory, which it seems a lot engines tuned for Xbox 360 were required to do because of the limited nature of the EDRAM in Microsoft's design.

I give developers more credit than that though. I think most of the problems on early Wii U games were due to the poor tools and support offered initially by Nintendo.

 

[freezamite]

If all the caches and EDRAM are used effectively, the machine shouldn't be bandwidth starved. Performance penalties would be pretty severe if you are constantly reading and writing from main memory, which it seems a lot engines tuned for Xbox 360 were required to do because of the limited nature of the EDRAM in Microsoft's design.

I give developers more credit than that though. I think most of the problems on early Wii U games were due to the poor tools and support offered initially by Nintendo.

Most launch-ports were rushed projects on unfinished dev kits. I think that the adaptability to the WiiU architecture depends on the engine the game was developed for, and the use of the Xbox 360 attributes that a certain game made of the Xbox 360.

I don't think that any of those games had enough time of development to adapt to the new architecture, ¡and even Nintendo said that until November they hadn't had the tools finished!

I think that most of those early ports didn't have the budget or the time to end up like they should, and as I said, the system could be bottlenecked on some other aspects that would translate into lower resolution or framerate if the game wasn't programmed specifically towards that certain architecture.

 

[OG_Original Gamer]

Memory seems to be the backbone of GPU design. There's SRAM in the core design. Thinking about WiiU memory focus, its apparent Nintendo wanted a console that's a lot more capable of reaching its theoretical limits.

What are the chances the SRAM in Latte, have a higher density and its kB are more than what's been suggested?

 

[freezamite]

Memory seems to be the backbone of GPU design. There's SRAM in the core design. Thinking about WiiU memory focus, its apparent Nintendo wanted a console that's a lot more capable of reaching its theoretical limits.

What are the chances the SRAM in Latte, have a higher density and its kB are more than what's been suggested?

I don't know about the kB, but the 3 big pools of eDram and eSram are confirmed to be 32MB, 2MB and 1MB respectively. If we could, based on this data, calculate how many eSram have those blocks on the ALU blocks, it would be really important in order to determine the ALU count or configuration.

 

[Earendil]

I base my comments on facts. Not some fanboy "hate or love."

That's rich...

 

[frankie_baby]

I don't know about the kB, but the 3 big pools of eDram and eSram are confirmed to be 32MB, 2MB and 1MB respectively. If we could, based on this data, calculate how many eSram have those blocks on the ALU blocks, it would be really important in order to determine the ALU count or configuration.

I seem to remember before marcam stated his figures the general consensus on the 2mb pool was either 3 or 4mb

 

[Fourth Storm]

I don't know about the kB, but the 3 big pools of eDram and eSram are confirmed to be 32MB, 2MB and 1MB respectively. If we could, based on this data, calculate how many eSram have those blocks on the ALU blocks, it would be really important in order to determine the ALU count or configuration.

That's pretty much exactly what I've done, except I used the 2kB blocks which Marcan identified as a point of reference, since they are closer in design to the SRAM blocks used as GPRs. I arrived at 64kB for each shader block - precisely the amount needed for 20 SPUs.

 

[freezamite]

That's pretty much exactly what I've done, except I used the 2kB blocks which Marcan identified as a point of reference, since they are closer in design to the SRAM blocks used as GPRs. I arrived at 64kB for each shader block - precisely the amount needed for 20 SPUs.



It was 3MB, because MEM0 is a combination of that 2 MB eDRAM pool and the 1 MB SRAM pool to the left of it.

Which were those 2kb blocks Marcan identified? Are they part of the 8bit CPU?
If there is 64kb per block, then I think that this 20 ALU per block count is precise enough, since I doubt that as memory centric this design is, Nintendo would reduce the amount of critical memory available per ALU.

 

[joesiv]

Also 160ALUs @ 550MHz with low powered 40nm process would consume drastically less power unless it was a high power design and cut down which isn't what we are seeing at all. (you are talking about ~10watts worth of silicon btw which is far too little for the GPU)

I don't care either way, but does that 10watts calculation take into account that the WiiU GPU does more than just GPU tasks? It also houses the system's south and north bridge functionality (access to RAM, and other IO), that stuff is not typically in computer GPU's.

I have no idea how much wattage such tasks would require though.

 

[Fourth Storm]

Which were those 2kb blocks Marcan identified? Are they part of the 8bit CPU?
If there is 64kb per block, then I think that this 20 ALU per block count is precise enough, since I doubt that as memory centric this design is, Nintendo would reduce the amount of critical memory available per ALU.

They comprise the pool labeled 24K SRAM on the bottom of the chip. Check his annotated image in the OP to see what I mean. I don't know where the 8-bit CPU is exactly, nor has Marcan indicated. That processor is specifically for converting the Wii video format to one compatible with Wii U/Radeon.

 

[Nilaul]

Why did Nintendo go for power efficiency (low voltage)? Rather then high voltage?

 

[Hermii]

Why did Nintendo go for power efficiency (low voltage)? Rather then high voltage?

Cause they are Nintendo.

 

[Nilaul]

Cause they are Nintendo.

Yes but that doesn't really mean that its cheaper does it? Less power hungry chips could be also more expensive?

 

[tipoo]

Yes but that doesn't really mean that its cheaper does it? Less power hungry chips could be also more expensive?

Lower clocks and lower power = higher chip yield rates in general, meaning less cost per chip. And smaller chips also generally consume less power. But all that aside, low power is kind of a Nintendo priority for whatever reason, they like their systems cool and quiet running. Is it "right"? That's subjective, but that's how they do it.

As for your thought that less power hungry chips can be more expensive, you're probably thinking of ULV ultrabook CPUs as an example, right? Those are more expensive because they are aggressively binned for their low power characteristics with the same architecture as more power hungry chips thus similar size per core, thus lower yields for the same die size per core, thus higher cost. In the Wii Us case, the chips are pretty small, and with such low clocks they don't need aggressive binning, so that's not the case.

 

[JordanN]

Cause they are Nintendo.

Not that it's always a bad thing. The real problem is, Nintendo chose the stupidest time to focus on "efficiency" in the face of PS4/720.

Focus on third party support first then worry about being a toaster.

 

[Nilaul]

Lower clocks and lower power = higher chip yield rates in general, meaning less cost per chip. And smaller chips also generally consume less power. But all that aside, low power is kind of a Nintendo priority for whatever reason, they like their systems cool and quiet running. Is it "right"? That's subjective, but that's how they do it.

As for your thought that less power hungry chips can be more expensive, you're probably thinking of ULV ultrabook CPUs as an example, right? Those are more expensive because they are aggressively binned for their low power characteristics with the same architecture as more power hungry chips thus similar size per core, thus lower yields for the same die size per core, thus higher cost. In the Wii Us case, the chips are pretty small, and with such low clocks they don't need aggressive binning, so that's not the case.

Still however they could had probably found something more powerful (or made something more powerful) for the same price?.

Perhaps the WiiU console would be slightly thicker (better/fans/larger heat stink), but it would be doable. On the other hand it wouldnt be so quite, and so "eco".

How much did the N64, GC and Wii Use?

 

[tipoo]

Still however they could had probably found something more powerful (or made something more powerful) for the same price?.

Perhaps the WiiU console would be slightly thicker (better/fans/larger heat stink), but it would be doable. On the other hand it wouldnt be so quite, and so "eco".

How much did the N64, GC and Wii Use?

The Wii only used 18W max. The Wii U uses 35W max. GC and 64 were very low too. So it's actually pretty high consuming for a Nintendo console, but for everyone else it's still a low power one.

 

[Hermii]

The Wii only used 18W max. The Wii U uses 35W max. GC and 64 were very low too. So it's actually pretty high consuming for a Nintendo console, but for everyone else it's still a low power one.

Gamecube was 23.

 

[Nilaul]

Gamecube was 23.

Wait wasnt it 12 volts?

 

[Easy_D]

No, just one. Its not plural. The Darksiders port is undeniably bad in all aspects. Someone tried to use it to make a claim that the Wii U required geometry to be down scaled despite it being opposite case in any game that had effort invested.



I'm pretty sure the 3DS has a LOT more power than the PSP all around as the 3DS is more powerful than the PS2.

http://www.youtube.com/watch?v=MgsXOexnOes
http://www.youtube.com/watch?v=rdA_l5FSS18

Did you know that MGS3D has downscaled geometry and textures while also having lower framerates overall? Granted, MGS3D is what I would consider a shitty port.

 

[baggagelizard]

Not that it's always a bad thing. The real problem is, Nintendo chose the stupidest time to focus on "efficiency" in the face of PS4/720.

Focus on third party support first then worry about being a toaster.

EA Home-torch :Burns down your house with Blockbuster Always-Online Content