Cache Coherency probably. i.e. updating local core cache if values change in one of the caches of some core. Or something like that.
It just makes sure the data is consistent.
Wii U hardware discussion and investigation *rename
- Thread starter AlNom
- Start date
- Status
Cache Coherency probably. i.e. updating local core cache if values change in one of the caches of some core. Or something like that.
It just makes sure the data is consistent.I thought Batman looked really bad, too, but I wasn't sure if the Wii U was just producing ugly games or if there was some aweful compression happening to the gameplay on Spike's stream (which otherwise has been beautiful in HD).
I will say this, but DOF must be practically free on the hardware becasue half the games shown so far are all going for a tilt shift photography look. It's Nintendo's version of #yearofthebow
Didn't seem true direct feed. It was just a filmed demonstration.
They were cutting back and forth between off screen and direct.
bgassassin
Regular
They are from the early target specs.
forumaccount
Newcomer
More 8 render targets
I don't get this:
Write gatherer per core.
Locked (L1d) cache DMA per core.
What does that mean?
Write gatherer per core is a technique to speed up writing out to memory by uh... gathering writes and sending them out as one. I'm probably hedging on details because the usage is basically just "you turn it on, and it makes writing memory faster" in some circumstances. It's similar to write-combined memory on xbox.
Locked cache DMA is a technique where the L1 cache is "locked" and used as a very fast area of temporary memory, similar to scratchpad on PS2 or a little like an SPU.
As for what it means... it means something that I'm not gonna say.
That the main memory is slow?
from the leaked specs, i read that the gpu has a tesselation unit (even if IIRC the r700 family didn't). Does that means that there is hope to actually see tesselation in Wiiu games? Xbox 360's gpu also had a tesselation unit, but as far as i know no game actually utilized it (maybe because of the huge cost in terms of computational power required)
The rv700 had a tesselator, as did the r/rv600 family before it. Less capable though than the rv800 family tesselator.
IIRC the Xbox360's tesselator was used in a couple of games: Viva Pinata, Forza 3, Halo Wars and Halo Reach.
Svensk Viking
Regular
I've read it was used for the water in Banjo Kazooie as well
The impression I got was that it has been used in a number of games (e.g. Alone in the Dark for displacement IIRC), but it's generally not worth discussing because of the triviality. Epic did add support for GPU tessellated surfaces back in 2008. They used it for fluid interactions, so I'd wonder about other games with similar approaches*. Those situations seem a prime candidate all-considering. There is stuff like terrain tessellation as well (ala Viva Pinata, but for larger scope, which makes sense for managing patch sizes), but it's hard to really say whether one title uses the hardware unit or not (Battlefield doesn't, Mass Effect might have for the first game).
The things lacking pre-DX11 would be the Hull and Domain Shaders, which make it easier to implement more complex/programmable forms of tessellation, as opposed to the relatively fixed-function stuff in previous generations.
*Arkham Asylum used the same sort of fluid surface for the one room with the water you have to cross that was electrified (IIRC). The surface interaction might have been missing on PS3/PC, can't remember. It was basically a check-box feature.
that's interesting, i did'nt know it was used ingame on 360. Regarding the wiiu, can we espect to see games with use of tesselation? (even if not in the same ammount and quality as seen in recent dx11 games) or not? the thing that puzzles me the most is that the api used by wiiu seems to be based on the opengl supported by r700 family, (version 3.3) that doesn't support tesselation at all.
Nintendo would have to come up with their own solution to expose the HW functionality in their API in that case. Even if the unit is limited to pre-DX11, there are ways to achieve similar results of DX11 but they require a more expensive, two-pass approach for the rendering, and that's a fairly divergent implementation from DX11. Devs probably wouldn't bother doing both.
Anyways, back to the waiting game for HW info leaks...
Anyways, back to the waiting game for HW info leaks...
The 32MB of eDRAM array in POWER7 is taking a mere ~66mm² on the die (without the L3 tags). And this is an implementation that has been accommodated for a much less tolerant high-performance architecture design. It's definitely doable/affordable for a tiny console, on any modern manufacturing process. Actually, I would even go for 48MB -- perfect size for a full 1080p back-buffer in FP16 format, with some leftover space for 2x multi-sampling.
Why the secrecy? It means U-CPU can do everything Gekko could. BTW, POWER7 also has lockable & DMA-able caches.
Why would you have 32MB Edram and do FXAA. Well, so far no game has not shown any AA
- Status
