I appreciate the response, Grall. I do not presume to be able to look at a scene and immediately identify why Wuu is choking and how that relates to hardware (especially alpha effects and such), so the experience of those here is quite welcome.
Yes, but there's not the slightest shred of evidence that says that information relates in any way whatsoever to the edram integrated into wuugpu. That's where your inferrence fails. It's just baseless speculation, it has no foundation.
It's an eDRAM technology developed by the company that we know is providing the Wuu GPU and eDRAM. They even say that it's targeted at games consoles! Perhaps there is some other type of RAM that Renesas are hiding, but it seems highly unlikely. It's still speculation, I'll give you, but baseless is selling it a bit short.
Grall said:
Yes, but as mentioned before, that bandwidth exists solely to support single-cycle 4x antialias combined with alpha blend. If wuu isn't designed with that capability in mind there'd be no point to have that much bandwidth at hand, especially if it only has 8 ROPs as suspected. As a comparison, the contemporary (from wuugpu's base technology) radeon 4890 has 16 ROPs and 128GB/s bandwidth.
I've been thinking about this one, and have concluded that you are probably right. After seeing Durango's set up w/ eSRAM at 102.2 GB/s and reading some of the explanations in the other thread, it seems that modern ROPs do not need the type of bandwidth that I was suggesting for framebuffer purposes. The other (and lowest) possible configuration of that UX8GD eDRAM entails 8 MB macros, each with a 256-bit bus. This is actually kind of intriguing, because at 450 MHz (the reported clock of the dev kit GPUs up until late 2011 ), that nets you 57.6 GB/s. This is the exact bandwidth of the RV770LE, some (surely downgraded) version of which was rumored to be used in the first dev kit. It's baffled many why they would choose that card to approximate Wuu's performance in the early days. Perhaps this is the answer.
Anyway, at 550 MHz, that would put eDRAM bandwidth at 70.4 GB/s. Probably good for 8 ROPs. One lingering question I have, though, is why would Nintendo stick to 8 ROPs? Would it not strike them that rendering an additional scene to the Gamepad would surely increase necessary fillrate? Have ROPs improved that much since Xenos?
Grall said:
I didn't say you should ignore it; that information is years old and is nebulously diffuse. Nothing specific can be derived about the hardware itself beyond what is stated from that tiny fragment of information.
I merely brought that up as you said the claim was never made that Wuu could pull of MSAA and right there it says it's capable of 4x at 720p. I don't know if that counts as "free" like on Xbox 360, but from what I've heard, that expression was a misnomer to begin with. I also doubt they've scaled back from what's on that sheet, so it should still be capable of as much, although I'm sure with many a sacrifice.
Grall said:
Yeah, but as mentioned, you don't need to emulate the texture cache specifically, in hardware, to run wii games on another system. You just let the game think it moved textures into the cache, while in reality it just sits right where it always was in main memory, and the GPU renders transparently from there with no penalty - since that's exactly what it's designed to do. Flipper on the other hand probably can't texture directly from main RAM at all, IE it would be limited in capability compared to modern GPUs.
Not sure about that last claim, although you may be right. From what I've read on Flipper, textures can be locked into the texture cache, but I'd imagine all other textures would still run through it in what space there is left. However, I don't think that pulling textures from main memory would work as you describe it in Wii mode. Some of those texture reads require very low latency, which would be impossible to match with off chip DDR3. Additionally, It just seems very unlikely and shortsighted that there would be no render to texture and such to the eDRAM. Again, the labeling as MEM1 points to it being used as a main pool if one desires to do so.
Grall said:
Why not. The underlying wii hardware is almost 15 years old by now. The wuu CPU is still code compatible to wii from what we know, it should be able to run the game logic directly with little to no overhead. The differences in GPU, sound and I/O can be offloaded to a software abstraction layer, running on the other CPU cores. Remember that dolphin is a hobbyist amateur project, nintendo obviously has a lot more resources to dedicate to their own emulator, including full hardware documentation of both systems and so on.
You are correct regarding the CPU being compatible, and from what I've read, Dolphin is very CPU intensive. I also doubt they'd even have to go through the trouble of emulating Starlet and the DSP. It's possible Nintendo are using a modification of the same DSP core which was used in Wii (they are clocked similarly at least) and even the ARM cores may be compatible. I have speculated in the past on the use of a Cortex A5, due to its small size and it being included in future AMD APUs as a security processor , but looking at Nintendo's recent history and the 3DS especially, I wouldn't put it past them to have stuck in a pair of ARM11s. They'd save a buck and have perfect binary compatibility w/ the ARM926 in Wii. Heck, they could probably even make a "Super 3DS" peripheral for Wuu then, if they wanted.
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.
