Wii U hardware discussion and investigation *rename

Can you describe in more detail what the issue is? According to the datasheet (http://www.skhynix.com/inc/pdfDownl...dram/Consumer_DDR3_H5TQ4G8(6)3MFR(Rev1.0).pdf) the part has 91 pins which must be connected for the 16-bit type. I'm only seeing something like 25 traces coming out of the chip in the picture, meaning the remainder has to be on other layers.

 

Sure, im really only concerned with the traces to the memory controller interface. I assume its on the mcm or integrated into the gpu or something.

I feel like there should only be 8 per chip, as i was under the impression a bit was sent twice per clock per trace, on the rise and fall of each frequency wavelength. Should there be 16 and the rest are just under the surface layer?

 

The traces to the memory controller are clearly not all visible either. You also see traces here that look like they go straight from one DRAM chip to another. That makes no sense unless they're connecting at another layer to also go somewhere else. Those are probably part of shared power, ground, and command/address lines. The data lines will be separate per chip.

Like Gipsel said, being DDR doesn't have anything to do with the width of the interface. People always refer to interface width in terms of physical pin count, so when it says it's 16-bit you can be sure there are 16 data lines per part. On this part they're labeled DQ0L through DQ7L and DQ0U through DQ7U.

 

Ah, that clears a lot up thanks. So the only wierd thing about it compared to others is how many traces they chose to have on the surface layer. So it is straight pin to pin.

So if those data 16 traces per chip go straight to the ddr3 interface on the gpu, we should have a pin for pin interface of 64 pins connected to these ram chips?

 

Honestly I disagree the only merit and ultimately the downfall of that piece of hardware is backward compatibility. To me for 200mm^2 worse of silicon, the same power in load and idle (30Watts), I think that that device sucks big time. Power is not that low and there is no power management feature, honestly looking at what is done on mobile device for a couple of watts really I don't think that 30Watts the WiiU burns are a saving grace for the design.

That I agree, those guys did what the management wanted to the best of their capabilities.

 

Yes but there are a bunch of other connections to the memory controller that aren't part of the data bus. Like command/address bus, clocks, chip select, bank select, and read/write enables.

I don't think there's anything weird about how many traces are or aren't on the top-most layer (other than that you can pretty easily see that it wouldn't have been viable to bring them all out on one layer). There are a lot of nuances that go into PCB layout, I don't expect it to be that obvious at a glance.

Lack of power management could be a software flaw, and it could be that Nintendo doesn't really care. And I'm not really sure why they should care, how much time are people spending sitting around on the menu? This is not a phone.

Even Broadway had a fair bit of lower power modes so I doubt the CPU lacks them, and I think by the RV7xx AMD had at least enough power savings to show a big difference between idle and full load..

What I do agree with is that the power consumption isn't really such a huge accomplishment, it just looks phenomenal compared to PS3 and XBox 360 because those designs were so incredibly inefficient.

 

Heh, well its certainly much less obvious than when I last put away my breadboard.

Thank you very much.

 

Well could be software and indeed the 360 is quiet a disaster wrt power consumption if you were compare it to what could be done from scratch on 40 nm process.
Anyway I still think the hardware sucks... lol
What I see (bc aside) is that 80mm^2 chip which include a GPU like a tegra 3 might give the wiiU a run for its money when it comes to CPU power. They burn a couple of watts.
They are lacking GPU power that sure and the associated power cost, they also use slow and low power memory. Still that let ~25 Watts on the tablet and more than 120mm^2 (as a part of the die and power budget is already taken by the GPU) to be invested on the GPU and faster IO.

I failed to see any of the company that could have designed such a product with such requirements (BOM which include RAM and power budget 35 Watts, leaving BC aside) if they were at that, be it Nvidia, AMD, ARM, Qualcomm or Intel (I discard companies that can't provide both the CPU and the GPU) could not have come with a design that doesn't significantly out perform the WiiU.
I would think that all those companies would have used less silicon if only to make up for the cost of a wider bus and faster RAM (DDR3) ( possibly more too).
I would also think that all those five companies would have come with a SoC on a 45/45nm process.
Edit Actually I believe that they could have pulled that level of perf for possibly cheaper /Edit

I'm just your average forum warrior, but I fail to see any engineering value in the decision made by Nintendo and how the system turned out, BC did crippled the system ceteris paribus (same BOM and power budget).

 

Yeah I don't really get the praise either. I could see Apple's A6X being within a factor of 2 of Wii U's GPU power and much closer in CPU power, while its peak power consumption will be like 1/6th... I'm sure many others could design an SoC, using only licensed IP (AFAIK you can scale IMG Series 5XT up to 16 cores so 6 or even 8 was always an option, and it can clock vastly higher than what Apple clocks it at), that matches Wii U in peak perf and blows it out of the water in perf/W, while using similar amounts or less area.

But Nintendo probably froze the design a very long time ago, far longer than a design gets frozen before going into a tablet. And I think part of that is a deliberate desire to have closer to production hardware during pre-launch development. So probably not just motivated

Another thing that I think could hurt Nintendo is a trend towards favoring Japanese suppliers and manufacturers. Not that there's anything intrinsically wrong with them, I just mean favoring local over what could be superior options. That's just my suspicion and not really based on anything they've said, but they seem to use more Japanese providers than others in the industry (including Sony). Like Fujitsu's role in DS and 3DS, licensing DMP for 3DS's GPU, and manufacturing using Renesas for Wii U.

 

* First of all, the game isn't restricted to the rates you mention; it is running 22 fps just as well. Since the camera doesn't move that much you can't argue that it spends 80% @50ms/frame and 20% @33ms/frame.
* Second of all, Flipper and Hollywood have a single backbuffer and a double frontbuffer. Do you claim that the XBOX, with 512MB of memory, only supports a single frontbuffer?

I like your scientific approach on this one.

Your assumption isn't correct. First of all it would only be able to reflect stuff in front of the camera, while the car in reality reflects the surroundings. Second of all, you mention Z yourself here. To use it, you must trace the reflected (NOT the normal) ray, compare the ray's depth with reflection map Z value. When ray's depth is greater than Z, THAT texel is reflected. Its the same concept as parallax mapping.

Funny thing, if you would trace the surface normals and add some attenuation, you end up with some form of GI (diffuse bounced light) .

You mean how much is drawn in the reflection maps? They probably leave out the road since it cannot reflect itself. But the entire road, and buildings reflect the surroundings (ofcourse, a wet surface has higher reflection factor than a dry surface)

You forgot to mention the address lines Back in the 90's DRAM was multiplexing the address using RAS and CAS signals, could they multiplex both data and address these days? Creaks did have a good point that late XBOX hw uses 4 chips, just as WiiU does. I read somewhere else that the chips have the same partnumbers too, which could mean twice the bandwidth we assumed at first.

 

No they don't have the same part numbers, they're not even the same memory technology. XBox 360 uses GDDR3, Wii U uses DDR3. There's no question on this, Nintendo (or Hynix) made zero attempt to obscure the part number or use anything non-standard, it's very clearly using 16-bit DDR3 Hynix DRAMs that you can find detailed in the datasheet I linked to. The only thing not apparent from the picture is speed grade; 1600MT/s is commonly cited so some other boards might have chips with marked speed grade. If this was somehow wrong the only higher grade is 1833MT/s, so not an overly dramatic change in available bandwidth.

 

Indeed there are quiet some option. I would assume in a lower CPU performance segment 9but great perf per watts and $), we saw Chinese company releasing quad Cortex a7 tied to a 544 mp2 GPU around the time the Wiuu was released (not sure of the process though but definitely though guys are on a budget too).
Even looking outside of the embedded realm, the good old bobcat would not have been that terrible, a dual core +1 SIMD is 75mm^2 and 18 Watts @1.6GHz. It is not too far strechted to assume that for 30 Watts, you could have a 128 bit bus to some faster DDR3 (possibly more than 2 GB) and a few extra SIMD. You could feat a redwood class of GPU+2 bobcat cores in may be 130mm^2 on TSMC 40 nm process. It gets even better if you use AMD VLIW4 architecture.

The weird thing is that we kept hearing of a constant changes in the rumors though it could have related to overall minor tweaking on final hardware (fixing the wiiumote wiuu communication, may be the clocks speed, and may be depending on yields playing with coarse grained redundancy /some SIMD could be disabled for yield).

That makes sense Pachter spoke of that in one of its vids, the magic of advisors boards and friendship blended with strong tradition and may be personal interest (shares) in the partners that are selected /crony capitalism

Edit
For the sake of the discussion there are quiet some reviews/benchmark of the Onda v972 tablet on youtube (among other places), within a tablet power constrain it still run the epic citadel benchmark in 2048x1440 and in high quality at 42FPS.
The device comes with 16GB of flash, 9.7" screen 2048x1536, the SoC Is a quad core A7+ sgx 544 MP2, on sale for 225$ on Onda website.

 

With vsync each frame is displayed for 1/30 or 1/20 of a second. There's no alternative.

The 360 version of the game has the behaviour of a double buffered game (which the 360 can under certain conditions achieve with a single buffer + whatever's in the edram) while the Wii U version may or may not be triple buffered. Double buffering means that if you just miss your update interval then you are likely seeing lots GPU idle time. You can not know how much just by looking at a frame rate counter.

To re-iterate, you can not do the type of maths you were attempting to do and calculate relative GPU power by dividing the frame rates (and then adding XX% extra power on top just because).

Hey, it's at least as scientific as your frame rate / GPU power analysis.

First of all I wasn't talking about the car, I was talking about the road reflections and made sure to point out I was talking about the road in all my posts. Second, I didn't assume what the techniques were, I said what I thought could be then done then asked you for the specific information you've seen on how the developers achieved their effects. Third, I didn't say you'd trace the normal to calculate visibility (where did you get this from?) - I said you could use the "surface normals that you'd already be calculating" in generating the reflections.

The point being that you'd already have calculated the surface normals (and could possibly have stored them), and would already have the colour and z buffers. I should hope that a GPU would be pretty damn quick at testing a ray against a Z value. It's a fraction of the work a proper raytracer needs to do.

 

While your criticisms are harsh sounding, I have to agree with you. And you didn't even mention the obvious on the CPU front. IBM's own 476fp would have been a fitting choice, and Nintendo could have stuck w/ the same partners if that's what they were looking to do. The whitepaper says that the core can even be made compatible w/ VMX. Even if they were set on sticking w/ Broadway, why only 3? Is it a magic number? Were they intent on merely matching 360? We're talking a few paltry watts here and a tiny bit of silicon. Similarly, on the RAM front, they could have doubled the amount of DDR3 and stuck it on a 128-bit bus and that would probably have made Durango ports a hell of a lot more feasible.

Alas, they made BC a priority, as if to almost purposefully buck the trends. Meanwhile, they still release the cheap Wii mini for no apparent reason. The flow of Wii games dried up years ago now and the Nintendo Selects line is insultingly small, even with many more million plus sellers to choose from. But as was said, designs were probably finalized years ago (the GPU has that 2010 copyright on the die after all), and Iwata hasn't exactly been prophetic in terms of his foresight as of late.

 

I meant quite literally, how much screen space is taken up by surfaces showing these reflections? Because you're not going to render a reflection map that is vastly bigger than the amount of screen pixels it will be mapped onto. ...Because that wouldn't make sense.

I believe wuu uses 8 chips. 4 on either side of the PCB.

 

If nintendo did freeze design that long ago to have closer to production hardware for pre launch they must have bungled something up quite feirce, as it appears they had practically no tool chains ready for third parties even around launch according to Criterion.

And judging by the horrible horrible void of wii u software even from nintendo themselves, i wonder if they even had anything ready for themselves.

I mean, they certainly werent working on wii games the past year or two. And theyve shown nothing of real note besides X, which is monolith soft....

Wonder what happened.

 

Nope, it's 4. With 8, maybe there would have been a chance of Nintendo saying, "Hey, maybe we should put this on a 128-bit bus!"

http://www.ifixit.com/Teardown/Nintendo+Wii+U+Teardown/11796/2

 

3DS was bombing so they were forced to shift the focus of their internal teams. Also, even if designs were finalized, it sounds like they did run into some troubles with the actual implementation of getting all components running in tandem on the MCM.

 

I did too, i actually solved that one a bit ago though.

The part number for wii's ramchip, was 'U3' It happens to be the exact same ram chip as the 360 uses.

So.... In many parts data bases that can be googled via wii u ram brings up the wii part 'wii u3 ram'.... With the same serial number used in 360's ram.

 

No way, I'm kind of defending the Wii U for once!

(Though not in terms of absolute performance. Hell no. It's awful.)

In the Wii Us power consumption defence we don't know what the AC adapter takes, a 6X BR drive could maybe take a handful of Watts, it's not using low power DDR3, and the Wuublet wifi is likely to almost always be powered up and transmitting hard. Plus aren't most high performance mobile devices on 32/28nm now? Tegra 3 is 40nm iirc, and doesn't seem like hot stuff tbh.