Wii U's Memory Bandwidth, GPU More Powerful Than We Thought?

Some new information has surfaced due to some in-depth research conducted by various engineers regarding the Wii U's handling of memory: it may be more powerful and faster than we thought.

Unlike the PS4 and the Xbox One, the Wii U is the only new generation console that has a lot of secrecy surrounding its hardware capabilities. While early kits and impressions from developers indicated that the Wii U was weak and slow and a “crap” system, further digging from die-hard members of the gaming community have summed up a possible cap for Nintendo's eighth gen system capabilities.

Some individuals have pointed to the fact that Renesas Electronics, who merged with NEC – the semiconductor company who was recently picked up by Sony, as reported by DualShockers – is responsible for the Wii U's semiconductor in the same way that they were responsible for the Xbox 360's semiconductor. The natural logic that follows is that newer tech made in 2012 would obviously be faster than whatever they produced in 2004 for the Xbox 360's release in 2005.

Keep in mind that the Xbox 360's bit bus per macro was 1024 nearly a decade ago, and according to information provided by Bob Peterson – regarding NEC Electronic's eDRAM for the 360 – the system was capable of expanding its bandwidth thanks to the external buffering from the eDRAM, writing in a Silicon Valley piece...

It's been speculated that this would translate into the 360 capable of through-putting up to 256GB per second. You can see how it all comes together in the diagram below.

This is juxtaposed with the Wii U's diagram, courtesy of Not Enough Shaders, which indicates that the Wii U's eDRAM is 32MB – equivalent to the Xbox One's eSRAM – and theoretically offers 4MB per macro. Check it out in the diagram below.

The general gist is that if Nintendo's GameCube had eDRAM at 32 macros on a 16bit bus width, as noted by EE Times, and NEC already designed Xbox 360's eDRAM die more than a half-decade before prepping for the Wii U's tech, then quite naturally – according to Moore's Law – the Wii U's eDRAM should be faster as part of the natural state of technological evolution. I mean, no one makes newer chips slower or bigger than previous chips, right?

It's been speculated that taking the information above into consideration, the Wii U's total bandwidth of gigabytes per second, including the possible 1024 bits per macro and GPU – which, according to TechPowerUp clocks in at 550mhz – would come out to around 563.2GB per second. Keep in mind that the Xbox One runs about 170GB per second of bandwidth between the DDR3 and eSRAM, as outlined by Xbit Labs.

This could explain the Wii U's ease of hitting 1080p at 60fps with nary many complaints from those who actually enjoy working with Nintendo's hardware.

This also points to possible scaling with the GPGPU and graphical output that hasn't been discussed before with the Wii U.

So what does the bandwidth of the Wii U's eDRAM have to do with anything? According to some die-harders out there, the Wii U should be capable of tessellation displacement since it has the bandwidth to handle those procedures with ease, thanks to the inclusion of NEC's proprietary eDRAM die for the Wii U. The importance of CPU/GPU fetch timing in correlation with tessellation is highlighted in a piece by Matthias Niessner in a thesis on hardware tessellation capabilities.

All of that is to say that perhaps the Wii U's design infrastructure lends itself toward forward-thinking scaling than we all thought before, despite a lot of Nintendoom talk from some developers.

Previously we spoke with Unity Technology's David Helgason about the Wii U's GPGPU scaling properties for things such as shader model 4.0 and Unity's ability to tap into the advanced features of DirectX 11. Helgason acknowledged that while the Wii U doesn't have 1:1 DirectX 11 capabilities, they would make it possible for developers to tap into equivalent DX11 exclusive features.

Interestingly enough, it wasn't but a short while ago that Teku Studios acknowledged that they would be utilizing the Unity Engine to bring DX11 equivalent features to the Wii U in their game, Candle.

When contacted about the Wii U's capabilities for direct tessellation displacement, however, Teku Studios denied to comment due to being under NDA regarding Nintendo's hardware.

DX11 racer Project CARS is also making use of multi-threaded support and high-end GPU features for the Wii U, but once again, when pressured as to whether advanced forms of tessellation displacement would be used, the team at Slightly Mad Studios declined to comment.

We did, however, get an off-the-record comment when asking about the Wii U's access to shader model 5.0, from a developer working on an upcoming Wii U title, who – under anonymity, of course – stated that...

He did go on to say that...

He also mentioned that direct access to these features through an API like DirectX isn't possible, but there are workarounds to get equivalent effects and results using the Wii U's GPGPU.

It's been hotly debated that even though the Wii U is capable of these things, the wattage cap prevents it from scaling, or utilizing high-end features in big, graphically demanding games.

However, software engineer Francisco Javier Ogushi Dominguez has argued that the Wii U has a lot more room to scale than we all originally thought.

According to Dominguez, he noticed that the Wii U has a class A external power supply. Class A means energy efficient and low on consumption, as noted by EDN, and outlined in the Government Energy rating.

The Wii U's power has been estimated on average at 33 watts when under load, according to Eurogamer.

Dominquez stated that...

He notes that this is already accounting for watts consumed for the games, disc drive, USB and SDHC.

The most striking of what he had to say was this gem right here...

Well doesn't that shed a bit of light on the situation?

This might also explain why Nintendo's first-party games look and run so well at high resolutions and stable 60 frames per second. They're tapping into the system's actual capabilities. Now the real question is: will third-party developers start tapping into the system's actual capabilities?