Wii U hardware discussion and investigation *rename

The front buffer is probably locked while the compression routine needs it. That'd make the buffer flip block until it's done, which would also block rendering from starting in the backbuffer. The locking may only happen long enough to copy the framebuffer into another memory space if that's faster than compressing it directly. Either one should be much faster than what the screen needs to display it, so the impact here is a lot lower than being vblank locked.

If they're okay with a similar kind of tearing on the WiiU display they could just lock the framebuffer while it copies single macro-blocks or macro-block rows, which would be a negligible amount of time.

With all of Wii's additional memory it shouldn't be a problem to triple buffer, so long as the latency is acceptable..

 

I agree, and there's more than system design that wouldn't impact the main rendering to TV out. However, the lack of any tearing in any Wuu games is suggestive of, perhaps, a system that is v-locked, and the Wuu blet out could be a reason for that. Then again, I don't know of any Wii games that tore, so maybe it's an artefact Nintendo won't allow either by requirement or hardware design, and Wuublet has nothing to do with it.

 

According to Digital Foundry, the Wuu delivers a full 720 signal to the Wuublet before it is downscaled there.

Am I reading wrong, or are they implying there isn't compression going on in the console? It sounds like the signal isn't touched until downscaled in the tablet.

If it really is basically a repurposed N wifi signal, shouldn't that be more than sufficient for throughput? I'm impressed there is apparently NO effect on latency when beaming to the Wuublet (LOVE that word, btw).

 

1280x720 x 24bits x 60 = at least 1.3 Gb/s plus wifi overhead and error correction.

Could they be using multiple channels? or 802.11ac ?

 

That is not going to work. Just take a 30 frames per second with 1280x720 resolution second and you arrive at an uncompressed data rate north of 600 MBit/s.

It makes much more sense to send a downscaled and compressed image. The controller would then just need to decompress it. And some test I've seen has already revealed some compression artifacts, so the data gets at least touched and compressed before sending it over.

 

They mentioned in another article that it looks like the signal is compressed with MJPEG. 720p pure uncompressed video is far too demanding, and pointless given the destination screen size (unless Nintendo are considering a Wuu XL with a 720p screen down the line ). I also don't know how you can tell if the video stream is shrunk before broadcast or in the Wuublet. It makes far more sense to do that in the console and save compression time and wireless BW. I think the real meaning here is that the 720p is downscaled to the Wuublet screen and not rendered at native Wuublet resolution.

 

anandtech do a teardown
http://www.anandtech.com/show/6465/nintendo-wii-u-teardown

 

Dated 18th November. You think we haven't seen this already? AlStrong broke the RAM BW prior to this AFAIK; he was certainly quoted in an amount of coverage during the release day.

 

Ok, I missed that article. I wasn't really thinking about the math so much as I thought I remembered something about a proprietary use of MIMO N for the Wuublet.

Why would they use MJPEG over something like OnLive/Gakai's use of h264/x264? If it works that decently on an internet connection, it should be pretty darn good on a 30 foot wifi N connection.

 

Sure

http://iwataasks.nintendo.com/interviews/#/wiiu/console/0/0

---

You are absolutely right, that's what I am wondering too. I mean even a Llano shouldn't have problems with such games at that resolution and it has ONLY DDR3, so the slow RAM can't be the reason.

 

Latency, needed processing power and licensing costs would be my guess.

 

710 won't help you. The ratios it used weren't magic, it was just appropriate for the design targets. As you pointed out, not all of the 7xx chips have the same ratios either.

The ratios for WiiU are appropriate for WiiU, and not necessarily dependent on other instances of the family it came from.

Some developer will eventually leak the clock speed. If they are really curious they will also write a bunch of simple test cases to work out the numbers you're asking about. Some surely have already, they just don't want to violate NDAs. But eventually it will get out.

 

lherre made another post about wii u and this guy always makes good posts considering his position

http://www.neogaf.com/forum/showpost.php?p=44832703&postcount=10892

"huge" performance difference between wii u and 720/ps4.

also fwiw his statement wii u >ps360 might be looked at as interesting news rather than a given given recent events. guessing the tablet is really sapping some power.

 

H.264 is easier on the hardware and dedicated encode/decode is implemented in all modern SoCs and MCMs. AirPlay Mirroring is also using H.264 to stream video and it works without a hitch.

Just look at the battery life the iPad has when playing back H.264 content, the iPad 2,4 (A5r2, 32 nm) gets nearly 16 hours of playback, the iPad 4 nearly 14 hours and the iPad Mini is good for over 11 hours.

 

Its always great to hear from lherre. Its like a big slap round everyones faces when he drops some knowledge (for both sides of the "power debate", that is and me included) He brings everyone back from the brink

I'd love to know exactly what the Gamepad requires, "power" wise, for say a 2D map or inventory compared to a 3D mirroring of the main screen. Would there be a difference? Will we ever be able to find out? The only reference I've seen to it was in a dodgy rumour apparently from a Crytek tester or somthing where they said the 'Pad screen was locked to "on", and they thought they could get more out of the system if they could turn it off. I dont think it mentioned what was showing on the 'Pad screen and the whole rumour sounded bogus to me so I never put much thought into it.

 

Yes. Mirroring requires no additional drawing beyond what's appearing on the TV. Any alternative graphics on the Wuublet are going to occur additional cost in their rendering prior to output, presumably at 720. That'll be very little impact at all in the case of a few sprites or a simple map, but it is still extra effort. Rendering a whole separate 3D scene will be the most costly option, but that's no different to rendering a complete 3D view in a rear-view mirror of a game, for example.

 

So it's unlikely any of these first lot of ports are suffering becuase they're doing too much with 'Pad then, as I dont think any of them are rendering much different than whats on screen (not at the same time anyway)? Does the resolution effect this? Presumably the image going to the 'Pad is 480p or somthing?

___________

Its interesting that DF keep mentioning V-Sync as being a bit of a bug bear. Begs the question really - why is it being deployed if its causing problems? Is it possible it's required to keep the 'Pad image in sync?

 

DF reckons the Wuublet is receiving a 720p video. It's safe to say it's displaying a downscaled 720p image from DF's investigation, but I imagine it's being transmitted already downsampled. Doesn't make sense to send a 720p screen and shrink on Wuublet.

Mentioned before in this thread if you've missed it. Might just be a Nintendo requirement - Wii games never tore. May also be linked to a requirement in supporting the Wuublet by needing a full frame prior to transmission, meaning no option to change framebuffer partway through the display transmission (tear). Can't tell what's going on at this point.

 

But there's a huge difference. The Wii U can't use a pre-compressed video stream for games, it has to compress frame by frame in real time in order to get reasonable latency.