Wii U hardware discussion and investigation *rename

I don't think that they included DP to begin with according to Wikipedia anyway, I lean towards smaller GPUs anyway as I suspect that given the inclusion of eDRAM and other logic allowances would need to be made and not all logic scales to the same extent and we have to consider for instance the possibility of blank space or less than ideal layouts given that these GPUs were not designed to be packaged with eDRAM of course I could be completely wrong...

 

I meant, that they may want to remove DP support from RV740 (if it would be the base) to save a bit of space, as RV740 definitely supports it (it is a shrunk RV770 with 2 SIMDs removed and a halved memory interface, it even shares the ASIC ID with the RV770 for the driver integrated shader compiler, so it has to behave identical for all related purposes).
So it possibly makes more sense to use either one of the later architectures (Redwood/Turks, better for GPGPU) or alternatively a nominally smaller variant of the R700 series (as a shrunk RV730) to begin with.

 

This might be a stupid question, but some guy who claims to be a licensed developer posted something weird on Slashdot, and I wonder if makes sense. The Wii U CPU, like the Wii and Gamecube CPU, uses paired singles. Obviously. Now, the guy claimed that, much to his surprise, the Wii U CPU had 96bit FPRs. I never heard of a CPU with 96bit registers, let alone a 96bit floating point unit, but assuming it was true, would such an extension even make sense in theory? Three paired singles per register? As a layman, the ability to manipulate a complete 3D coordinate at once with only two registers seems handy, but It's quite possible I'm missing something...

Yeah, that's the comparison I meant. I see, so that's not really all that conclusive.

 

What Im asking is if the WiiU could be using some kind of special memory buffer ?

 

You mean like the eDRAM that's been mentioned plenty of times?

 

Maybe a 3 core CPU with 32bit and he's just adding them up to get 96bit?

 

That does not make sense as he's talking about 96bit register files. They should be 64bit wide (at least they were), not 32bits in each core.

And a 3D vector would be kind of awkward, as one often needs 4 components anyway (and the size difference of a 3x32bit to a 4x32bit vector unit is probably not huge). If it is not made up, one could have the idea of the support of some reduced precision format (4x24bits) in the same regs, but that does not sound very convincing to me. Other ideas?

 

I see the eDRAM used for caching.

 

That's what I thought, too.

As I said, the shader array of RV740 is just a shrink of the RV770's SIMDs to 40nm (with two SIMDs removed) and not a sized up RV730. They obviously didn't change anything compared to RV770 there. They are identical from a functional point of view. So it isn't a real difference to replace one for the other (besides the process and power consumption of course).

 

Some weird 4x24bit fp SIMD?

 

Talking about ram... Why we don't have some developers complaining about slow memory?

 

Maybe the memory is fast compared to the CPU.

 

Then, the "slow" ram is not a problem?

 

I were to post something about function's post because it got me to laugh, I passed because of self discipline to avoid the OT.
As you did, I may answer you that whereas his post has most likely ground in reality, my sarcasmometer went high with a matching laugh, I regret the reputation system that was a damned funny and good post worth "ten points for griffindors"

 

1 square mm is 2 mbyte in this case.
16 square mm is 32 mega byte?
in that case 64-128 MByte should be the number with 130 + die size

But somehow I feel that quite unrealistic.

 

I said that already and asked for other ideas.