Wii U hardware discussion and investigation *rename

[thatdudeagain]

Instead of asking about alot of hyperbolic bullschmutz of what and what can and cannot be done on Nintendo's uberware. Iets take a look at what it is doing that I myself don't see on ps360....First,Nintendos second wave of software has a lot of native 1080p games coming, some at 30 fps, some at 60 fps, all rock solid. Is it really memory bandwith limited? Nintendos history has them working the best out of limitation, as their whole lineup of systems from the NES on have had poor cpu's and built in hardware work arounds. Doesn't this system also use some form of compute in the gpu? Although we don't know what this system can do, I'm looking forward to what it will do in time, along with any complex hardware.

 

[Shifty Geezer]

...lets take a look at what it is doing that I myself don't see on ps360.

That is indeed a good approach, but it ought to be tackled in a more structured fashion. Not everyone is keeping tabs on Nintendo's Wii U library, so it's hard to discuss what the software is achieving. I recommend links to images and videos showcasing particular features and your interpretation.

For example, Donkey Kong was mentioned as a 1080p title, but a screenshot immediately shows the graphics aren't particularly taxing which accounts for the extra resolution. That's not to say PS360 could render the same game in the same quality at 1080p, but be clear this isn't a versus thread; it's a hardware breakdown and analysis thread. The game results should only be compared as evidence of what's in the silicon. eg. A significant evidence of high BW via plentiful high-res alpha blends comparing titles across Wii U and PS360 would be evidence of faster eDRAM over slower eDRAM.

Doesn't this system also use some form of compute in the gpu?

Well, any GPU can be used for compute via GPGPU. I don't recall if we even identified what architecture Latte is using to know if it has compute by design or not.

Although we don't know what this system can do, I'm looking forward to what it will do in time, along with any complex hardware.

This a tech investigation thread, so discussion should focus on the hardware and not one's hopes for the system, nor one's appreciation of Nintendo software design.

 

[Goodtwin]

I don't think there's any evidence for that. It's a theory postulated by a Nintendo fanboy who made a couple of correlations between vague PR comments and a Renesas tech sheet, and concluded their widest bus eDRAM must be in Latte. That's the only argument I've seen, anyhow, and that's all my GoogleFu can find on the theory.

It's in this thread. After someone posted a truly crazy 500 GB/s theory (that they've added to Wikipedia, so must be true...), people challenged that and two figures were presented < 35 GB/s. But also unsubstantiated. I don't think there's any decently supported theory for the BW. The only thing I'm comfortable recognising is that there isn't stupid amounts of BW in there (and so probably not a super-wide bus). It only made sense on PS2 because it used multipass rendering. Modern shader architecture doesn't need massive overdraw, so super massive BW is of limited value if the rest of the system components aren't enough to use it. I can't see any evidence in games of super high BW either (even just looking at first party titles).

There's an IGN thread where a lot of the contributors in this thread are still going at it, with speculation of 70 and 130 GB/s.

Thankyou for that info on the PS2, I didnt know that. I also agree that I doubt theres crazy high bandwidth to the edram. I had always heard estimates putting it around 70GB/s, and that made sense to me from the perspective that its still only 32MB, so even if it were much higher than that, its usefulness would still be more limited. The textures would still need to come from the main memory pool. Having an abundance of bandwidth isnt useful anyways unless the hardware can use it. Obviously having plenty is always nice so that it never becomes a bottleneck, but once theres enough to never be a limiting factor, there is benefit to having more.

 

[Exophase]

AFAIK ~70GB/s is a realistic upper limit. You can get it by counting the columns of the eDRAM macros on the die shot, which gives you 1024. At 550MHz (decently publicized GPU clock speed) that gives you 70GB/s.

There's no such thing as a standard eDRAM bus size, you configure foundry provided macros into a bus arrangement that makes sense for your chip design.

 

[Goodtwin]

AFAIK ~70GB/s is a realistic upper limit. You can get it by counting the columns of the eDRAM macros on the die shot, which gives you 1024. At 550MHz (decently publicized GPU clock speed) that gives you 70GB/s.

There's no such thing as a standard eDRAM bus size, you configure foundry provided macros into a bus arrangement that makes sense for your chip design.

Ok, thankyou for clarifying that.

 

[AlNom]

AFAIK ~70GB/s is a realistic upper limit. You can get it by counting the columns of the eDRAM macros on the die shot, which gives you 1024.

hm.... aren't the bit lines horizontal in the Chipworks shot? They're the ones connected to the yellow strips (controller etc), in which case , 512-bit. For the smaller eDRAM partition, the bit lines would be vertical then.

/iphone disappear me

 

[BRiT]

AFAIK ~70GB/s is a realistic upper limit. You can get it by counting the columns of the eDRAM macros on the die shot, which gives you 1024. At 550MHz (decently publicized GPU clock speed) that gives you 70GB/s.

hm.... aren't the bit lines horizontal in the Chipworks shot? They're the ones connected to the yellow strips (controller etc), in which case, 512-bit. For the smaller eDRAM partition, the bit lines would be vertical then.

For those playing along at home, that would imply ~ 35GB/s as a maximum upper limit.

 

[Goodtwin]

For those playing along at home, that would imply ~ 35GB/s as a maximum upper limit.

I suppose that is still possible. I guess it comes down to how memory bandwidth is sliced up. We know that the edram is used for things like the framebuffer/z-buffer. The thing I would like to know, is how much bandwidth is typically eaten up by those things. I remember the Gamecube had 2MB of embedded memory on the GPU to store the Z-buffer that saved a ton of bandwidth to the main memory. I dont know the specifics, but I believe Hyper Z from ATI did something similar. With the overall performance of the Wii U being what it is, 35GB/s from the edram with an additonal 12.8GB/s from the DDR3 memory, it very well may be sufficient.

 

[Exophase]

hm.... aren't the bit lines horizontal in the Chipworks shot? They're the ones connected to the yellow strips (controller etc), in which case , 512-bit. For the smaller eDRAM partition, the bit lines would be vertical then.

/iphone disappear me

Yeah, what I posted was totally based on what people were saying after the die shot was released, I should have looked at it again myself. Just did so now.. I'm not at all good at deciphering this stuff so it could be totally wrong still. But it looks like it's split into 16 blocks with a data bus on the left side and a much smaller address and control bus on the top or bottom of the right side. It's hard to tell exactly how many traces there are on the buses even with the highest resolution shot but it looks like very roughly 128 on the data bus. But there also seems to be around 40 for the address bus, which seems too high for pure signal count (should need 25 pins max, probably at least a few less). So the data bus width could be far below 128. Still, that suggests 140GB/s max if it's 550MHz SDR.

70GB/s should easily be sufficient. 35GB/s would be on the low side.

 

[Shifty Geezer]

35GB/s from the edram with an additonal 12.8GB/s from the DDR3 memory, it very well may be sufficient.

Yes, it's comparable BW to its other console peers and we're getting the same sort of results on screen. 35 GB/s would be a legitimate choice given Nintendo's design philosophy. That doesn't prove it of course, but there's little reason to exclude the notion on account of 35 GB/s not being very much for a modern eDRAM setup. More than 1024 bits, 70 GB/s, seems highly improbable to me.

 

[AlNom]

Could they have chosen single-ported eDRAM to cut down on area/power :s

It's hard to tell exactly how many traces there are on the buses even with the highest resolution shot but it looks like very roughly 128 on the data bus. But there also seems to be around 40 for the address bus, which seems too high for pure signal count (should need 25 pins max, probably at least a few less).

I wonder if those traces are something else though. I mean, not all the pins on the DDR3 bus are actually for I/O alone (for example), and the traces don't line up with the arrays...

Yes, it's comparable BW to its other console peers and we're getting the same sort of results on screen. 35 GB/s would be a legitimate choice given Nintendo's design philosophy. That doesn't prove it of course, but there's little reason to exclude the notion on account of 35 GB/s not being very much for a modern eDRAM setup.

Certainly an improvement over RSX for framebuffer alone. RBE/ROP design seems pretty straightforward, but the cache sizes there must have improved since the earlier architectures (aside from format support) + better Z-compression/z-clear/hiZ. Then there are improvements to the cache hierarchy for shader/tex...

I suppose it's not confirmed whether or not they can texture from eDRAM, but that ought to be a win. Not sure if there's a reason why it couldn't. *shrug* Fuzzy memory after thousands of posts. :3

 

[TheD]

The CPU limits to number of cars to 6 online in Need For Speed when Mario Kart 8 will have at least 12 (Mario Kart Wii had 12) and run at 60fps? Hmm, doesnt really add up. My point about BO2 was more so about the number of players, and I have the game and there is no doubt that it doesnt hold 60fps in Ground War, it doesnt on any console for that matter. The idea that the CPU is the limiting factor for 6 players online is not backed up by anything and makes no sense.

Nothing says that the karts in Mario Kart (nor the players in COD) have the same CPU load as the cars in NFS (and you are also ignoring the traffic in NFS).
That is also before taking into account the different CPU loads each of them have before dealing with cars/karts/guys with guns and thus how much CPU time they have left over for them.

 

[Goodtwin]

Nothing says that the karts in Mario Kart (nor the players in COD) have the same CPU load as the cars in NFS (and you are also ignoring the traffic in NFS).
That is also before taking into account the different CPU loads each of them have before dealing with cars/karts/guys with guns and thus how much CPU time they have left over for them.

I sUppose its pure speculation on both our parts, but yes, I do think 18 players in COD shooting weapons is most likely far more cpu intensive than the cars in NFS. Burnout on Gamecube had traffic similar to NFS.

 

[loekf]

In other news, the GamePad has been "hacked":

https://docs.google.com/presentatio...v7-YH_A0LZO0Phxedh9deiE/edit?pli=1#slide=id.p

Some high/low lights:

- Custom ARM SoC with embedded H.264 codec. Camera images are also encoded into H.264.
- ST micro for sensors
- Broadcom 5 GHz Wifi
- WPA2/AES-CCMP is used with WPS, they managed to get bypass WPS (weakest link)
- Streaming to the GamePad works from a PC, but still buggy

I'm a bit surprised, they didn't use encrypted firmware if they are so keen on protecting their stuff... the WPS got basically hacked because code could be analyzed... I wouldn't call reading out a SPI NOR flash "expert tooling".

 

[Grall]

There's no threat to software by people hacking the wifi protocol to the gamepad, so it's not that big a deal. I doubt hacking the pad opens up a point of entry deeper into the console...

 

[creaks]

Nothing says that the karts in Mario Kart (nor the players in COD) have the same CPU load as the cars in NFS (and you are also ignoring the traffic in NFS).
That is also before taking into account the different CPU loads each of them have before dealing with cars/karts/guys with guns and thus how much CPU time they have left over for them.

what you guys are talking about sounds more like something pertaining to how much is invested on the particular products server than anything client side to me.

I sure as hell wouldnt waste money on a server network that handles a bajillion clients on the wii u, when you will literally have all of maybe a 1000 people ever playing at once. Id find something thats been sitting in a storage room for a few years, cut down, stretch out... eh good enough...

I believe it may be more pertinent to nintendo to have better server side performance for their software on their system than it is to 3rd parties...

 

[function]

Almost all console games are user hosted, meaning it's the CPU in the consoles themselves that have to be able to handle the multilayer components.

Besides, even if they weren't, the max number of users per lobby is a separate issue from the total number of users online looking for games.

NFS was built around 8 players sessions. The idea that on the Wii U they capped the max game size at six to make the game better for the players (like that guy said) is kinda funny.

 

[creaks]

Almost all console games are user hosted, meaning it's the CPU in the consoles themselves that have to be able to handle the multilayer components.

Besides, even if they weren't, the max number of users per lobby is a separate issue from the total number of users online looking for games.

NFS was built around 8 players sessions. The idea that on the Wii U they capped the max game size at six to make the game better for the players (like that guy said) is kinda funny.

Gross. I have to admit, all of my console games i used to play online... had their servers shut down on me.... I havent played any shooters or really any normal multiplayer fare since bf 1942... Especially not on consles. I did stuff more like pso and mh, than anything peer 2 peer like racing and shooting. I didnt even think about that.


But, that most definately places the issue on the netcode. Especially with peer to peer, the smaller your user base, the more spread out your systems are likely to be over your supported area, the worse your host system is going to be stretched, as the liklihood of each new member being outside the desired range increases, the worse your performance. I can definately see why they reduced the number of players when considering how low the player to area density was likely to be.

 

[Goodtwin]

I find it equally hilarious that a someone makes an assumption that NFS:MW for Wii U cant handle 8 players online. If you were to say that it was due to time constraints, NFS:MW U was ported in about 3 months time, but to say the Wii U hardware cant handle a racer with 8 cars online is just crazy. There are well thought out criticisms of the Wii U, and then there are statements that only make sense when your trying to paint the Wii U in the worst possible light.

 

[TheWretched]

So then... they just removed two players from the Online Mode just because... why? I am not saying it's impossible, but there's a reason. And since the GPU and the RAM size is better than on PS360, it more or less only leaves the CPU as the culprit.

I am quite sure that the WiiU "budget" for those games is miniscule compared to the rest, so... there's the reason of "making it work".