Wii U hardware discussion and investigation *rename

But we know the EDRAM isn't that big...

 

32MB is a lot larger than the 10MB in the XBox 360 when considering ports that are the same resolution. And you benefit on bandwidth not just from real textures but render to texture, where you don't increase the capacity requirements, don't have to resolve the back buffer, and don't have to read it back in.

An EDRAM you can texture from would also be less likely to have multi-sample ROPs built in (since those aren't meant to be read at all) which could give it a more modest fill-rate particularly with AA. Do we know that the 32MB is one dedicated chunk and not partitioned for different units like on Gamecube and Wii?

 

Then the answer is that no, we do not know that it's one block of EDRAM. Can someone link to where it's described as 32MB in the first place?

 

Yes, I've already outlined how it could be used as a texture cache, similar to PS2's EDRAM - the scene is probably rendered in relatively small batches, like ground, static objects, dynamic objects, foliage, characters etc. so setting up each of these batches could also mean clearing the EDRAM and loading completely new textures, many many times during the rendering of each frame.

There might be some room to play with shadow buffers too, although some games would prefer to use large cascaded shadow maps which can eat a LOT of memory and that can't be freed up during most of the frame.

So in effect it could be somewhere between ~8 and ~22 MBs... not sure if that's enough.

 

If you believe the xbox rumors in the other thread it's the same size as the embedded memory (whether it's esram or edram) on that one.

 

Yeah but the next Xbox won't have a 12GB/sec bus to the main memory either, so it does not have to try to cache textures into the EDRAM, it can use it for frame buffers, G-buffers, shadow buffers and such only.
I also believe that it will have a LOT of bandwidth.

Whereas the Wii U may need to rely on the EDRAM just to keep up with the current Xbox. Not to mention how much extra programming and data reorganizing such a texture caching system would probably require, if it can be implemented at all.
In this case that 32 MB would have to be compared with both the 10MB EDRAM and the 512MB main memory of the X360, and that's why it would be relatively small.

So the two cannot be compared at all.

 

Things do change at least a little if the texture cache can load both from EDRAM and main RAM, instead of just one or the other as is the case with PS2 and XBox360 respectively. I don't know what texture use is like in a typical frame though, if there's little actual reuse then it doesn't make that much of a difference.

I remember reading that there were some hardware functions in Gamecube/Wii that helped for streaming data to texture memory, although not treating it as a full on cache. I can't for the life of me find any real information on this. :/

 

In that case this all seems to rest on your assumption that it is there to cache textures. I don't believe I've read that in anything Nintendo has said about it. It's been called MEM1 in numerous places and if you look at the Wii specs, "MEM1" there is not a texture cache. Why do you think that changed?

You believe that 32MB of embedded xbox memory has a lot of bandwidth but 32MB of embedded wii memory doesn't? Why?

 

It is an assumption, yes, that the feeble 12GB/sec has to be augmented to keep up with the combined system bandwidths of the competing systems.

I just called it 'cache' to indicate the function it is used for, and not that it is a hardwired cache memory. It'd have to be managed from software completely (or maybe not?) and only "act as a cache".
The PS2's EDRAM wasn't a hardwired cache either, but the technique I've outlined has been developed on that platform, to utilize its strengths as much as possible. Otherwise both the entire framebuffer and all the textures would have had to fit inside just 4MB.


As for the bandwidth, as others have already indicated it is very likely that alpha blended effects are bottlenecked by it, and also the connection to the GPU die can't be that wide.

Xbox360 overcomes this issue by moving parts of the GPU - the ROPs - to the EDRAM die, so that a very wide bus can be created within that single die.
It is reasonable to assume that the next Xbox will continue to use this approach. As for the Wii U, we don't have enough information to be certain - but again, real world performance characteristics suggest that the bus isn't wide.

 

I believe it''s very likely limited in WiiU because all the ports are running at the same resolution as the 360 version. Turning up the resolution or enabling multisampling is trivial unless some aspect of the hardware gates performance, either that is that the WiiU is limited to 8Rops like 360 or because the bandwidth to EDRAM is limited.
If it only has 8Rops there is no point in having much moer memory bandwidth to EDRAM than about ~25GB/s, unless it can also be used as source for textures.

On 720if you believe the current rumors it would need AT LEAST 100GB/s out of the EDRAM to be competitive.

 

What separate edram die? The MCM pictures direct from Nintendo and from various post-launch teardowns show 1 small CPU die and 1 bigger GPU die. There isn't a separate edram die. The GPU and the ROPs are on the same die as the edram.

 

He was referring to the 360 wrt the edram die.

 

Actually I was a little tired already But ERP has also mentioned the performance, if there was a lot of extra bandwidth available then the Wii U could run at 1080p most of the time. Yet not even Nintendo's own games - that have a relatively low graphical complexity - are going above 720p usually.

As far as I know Trine 2 runs at 1080 - but it's basically a side scroller with low complexity, too.

All in all, if there was any kind of a game changer feature in the hardware beyond the specs we know and the specs we've deduced, it would have shown somehow. If it can't be utilized in ports then it can't give enough of a boost in the future either. Ports dropping to 15-20fps regularly would require a performance boost of about 50 to 100% and there's no way to hide that much power without any of the big studio developers finding it.

 

As I read it he was comparing it with the 360 setup and saying that the 360 is vastly better because the GPU/ROPs are on the same die as the EDRAM, and that the WiiU setup is weaker because effects are bottlenecked by the bandwidth so therefore the EDRAM connection to the GPU die was smaller. But there is no separate GPU vs EDRAM die setup so that's not a valid point.

If anything the separate GPU and ROP+EDRAM dies of the 360 creates an additional bottleneck that isn't present in the WiiU, where the entire GPU and the EDRAM are on the same die. If you render to a buffer in EDRAM and then want to use that as a texture, you don't have to copy it out to external memory first. That copyout operation isn't free, it eats up bandwidth in both memory types.

The consensus seems to be that the target was 360/ps3 level performance at half or lower power and lower cost. If that's true, why would it have more than the 8 ROPs of a 360?

The 360 EDRAM only provides 32GB/s of bandwidth, which isn't far from ERP's estimate for 8 ROPs. If WiiU's ROPs and EDRAM are similar in performance then the only difference is the approximately 40% slower external memory. The total bandwidth would be a smaller difference, 52 GB/s (32+20) compared to 44 GB/s (32+12). In many cases improvements in texture compression can make up for some of that difference. It doesn't need to be blazing fast to do what it was designed to do.

 

The 360 edram provides 256GB/s. The bandwidth between the dies is 32GB/s.

 

Are you sure it isn't 256 Gbit/s, which would be 32 GByte/s? If it's really 256 GByte/s then isn't that an extreme amount of overkill for the pixel pushing power? You won't see that a total total bandwidth like that on any of the new consoles, and they are showing up 6-8 years later.

 

256GByte/s, pretty sure. 10MB of edram with 32GB/s is pointless.