Wii U hardware discussion and investigation *rename

Status
Not open for further replies.
"Code optimised for the PowerPC processors found in the Xbox 360 and PlayStation 3 wasn't always a good fit for the Wii U CPU"
I'm curious about this. Why wouldn't it be a good fit? The numerous optimisations needed to get decent performance from the PS360 CPUs naturally benefit any CPU, or certainly don't make them worse, and it's the same ISA, no (not that anyone using a compiled language will even care)? I'd have thought as long as the vector units were comparable, code could be ported and run decently on Espresso, with only things requiring high linear clockspeed (math crunching) being an issue.
 
I'm curious about this. Why wouldn't it be a good fit? The numerous optimisations needed to get decent performance from the PS360 CPUs naturally benefit any CPU, or certainly don't make them worse, and it's the same ISA, no (not that anyone using a compiled language will even care)? I'd have thought as long as the vector units were comparable, code could be ported and run decently on Espresso, with only things requiring high linear clockspeed (math crunching) being an issue.

Well the WiiU doesn't have any vector units as such. It has paired singles for 32-bit float, while the 360 has 128-bit SIMD for both int and float. I've read developers here talking about arranging their integer workloads so they can squeeze extra performance out of int SIMD, so that might be one type of arrangement that doesn't naturally suit the Wii U?

I guess cache optimisations could be another area? A 1 MB shared L2 might benefit from setting all three cores / six threads on a shared dataset, but with the WiiU's wonky 1 x 2MB plus 2 x 512 MB might dick around with both cache optimised datasets and snooping eachother's L2 (which probably quite slow).

... or ... something?
 
Pretty much confirms what it seemed like to me. They haven't even looked at what users expect and are accustomed to using.

I mean, I just thought they'd looked but seem things differently (wrongly). But they hadn't even looked!?!?

I wouldn't call it incompetence, but wilful ignorance. They could easily change their approach and improve their offerings - I don't think they're too stupid to be able to match other's offerings. They just choose not to look at the wider market. Perhaps that is incompetent management? The saddest part is that much Nintendo discussion ends up being derisive of the company approach, even in this supposed tech discussion! ;) The Nintendo Way has such an overbearing influence on Nintendo products that technical discussion has trouble getting noticed.

It is hard to look at Nintendo's tech in isolation from Nintendo's overbearing management decisions, as when you look at the die shots you see ... Nintendo. A disciplined mind would find this easier, but my mind is not disciplined. :eek:
 
Well the WiiU doesn't have any vector units as such. It has paired singles for 32-bit float, while the 360 has 128-bit SIMD for both int and float.
that coudl make a significant difference, and the wording of the article/secret developer is just odd in saying PPC is itself an issue. Or does 'PPC' include the SIMD units by default and lack of them in Espresso means Espresso isn't properly PPC?
 
Newer PPC cores feature SIMD, but remember, wuu's CPU is from fking late 1990s, where such newfangled tech was still very new. Intel CPUs didn't get float SIMD until pentium 3 IIRC. In car terms, wuuCPU is a 1960s era car engine, and not a US large-bore V8, but an euro 4-banger.
 
Bad example given the utter incompetence of american engine builders.

In 1956 Ferrari had a 4 cylinder engine outputting 280hp. The 1964 - 66 Mustang, the example of american muscle, a decade later, had a big, heavy v8 outputting a whopping... 271hp in it top model.

So I guess there must be some truth in rumors about the Wuu's untapped power after all :D
 
The big, heavy V8s of the era did have monster torque, that I doubt the ferrari engine came anywhere close to. In any case, bad car analogies or not, the wuu CPU is not a ferrari engine of ANY time era... ;)

EDIT:
That linked article by the way - damn. That it would be bad I just knew, but THAT bad... It's like nintendo totally sat on its hands with both thumbs up its butt during all the good wii years, and then only towards the end start to realize that damn, they needed a new console, FAST! And jeez, it would have to have online support, crap! We don't have any of that!

*sigh*
 
Last edited by a moderator:
Bad example given the utter incompetence of american engine builders.

In 1956 Ferrari had a 4 cylinder engine outputting 280hp. The 1964 - 66 Mustang, the example of american muscle, a decade later, had a big, heavy v8 outputting a whopping... 271hp in it top model.

So I guess there must be some truth in rumors about the Wuu's untapped power after all :D

Your example is also flawed..hp per liter isn't everything...there are other factors like torque, fuel consumption, complexity, reliability etc.

GM/Chevy LSV8 series is one of the most powerful and reliable engines in the world and it's hand built, small and compact and lightweight and fairly fuel efficient as well. Many racing/tuning shops choose these engines to put into small sportscars because it's such a compact engine yet outputs loads of power/torque. They also don't cost tens of thousands of dollars like a Ferrari engine...lol. Ferrari engines are VERY high maintenance.
 
Last edited by a moderator:
I'm curious about this. Why wouldn't it be a good fit? The numerous optimisations needed to get decent performance from the PS360 CPUs naturally benefit any CPU, or certainly don't make them worse, and it's the same ISA, no (not that anyone using a compiled language will even care)? I'd have thought as long as the vector units were comparable, code could be ported and run decently on Espresso, with only things requiring high linear clockspeed (math crunching) being an issue.

Translate "Code optimised for the PowerPC processors found in the Xbox 360 and PlayStation 3" as "SIMD" and it should be more clear.

that coudl make a significant difference, and the wording of the article/secret developer is just odd in saying PPC is itself an issue. Or does 'PPC' include the SIMD units by default and lack of them in Espresso means Espresso isn't properly PPC?

Odd question... VMX is probably an optional part of the spec. Even the PS3 and Xbox 360 had slightly different vector units and no one claimed one or the other was any more or less PPC.

Well the WiiU doesn't have any vector units as such. It has paired singles for 32-bit float, while the 360 has 128-bit SIMD for both int and float.

This is pedantic but the int support was removed from Xbox 360: http://en.wikipedia.org/wiki/AltiVec#VMX128
 
Last edited by a moderator:
Odd question...
Not at all. I'm trying two correlate two disparate pieces of information. Xenon, Cell PPE, and Espresso are all PPC, yet we're told Espresso has trouble running the PPC code form PS360.

Translate "Code optimised for the PowerPC processors found in the Xbox 360 and PlayStation 3" as "SIMD" and it should be more clear.
That was my first suggestion, pointing the confusion to a developer choice of words. But there's no harm in asking for validation. ;)
 
Bah. Car games are mindnumbingly boring. Unless the cars have machine guns, missiles and mine launchers, nitro boosts and race through an obstacle-filled course a la Rock'n'Roll Racing or such.

Also, car games = typically all rigid polygon models, usually no deformation whatsoever, certainly all-rigid track and terrain. Not technically exciting in the slightest.

The guy sounds like he's PR spinning for the fanboys to hype his game. Very likely the "hidden power" he's talking about is simply good art and not much more, it's really hard to see where there would be much in the way of hidden power in a 35W, 40nm silicon process system.

What you say about most racers is why i cant stand them... And also why I love excite truck, which was anything but.

The damage system for excite truck was AMAZING for wii. Had to be using tesselation with procedurally generated maps for vertex generation and displacement. Each crash was something to be relished as each impact made its unique mark, according to the size, speed and direction of the impacting object. Was very dissapointed this was removed from the sequel.

Used the technology again in sports resort sword slicing and skyward sword slicing/sand displacement.

That would have to be broadways work i'd think. Wonder how nintendo will use it for espresso... Or would they rather use their gpu geometry shaders...
 
I don't think I was saying that, what I meant was that car games are technically relatively uncomplicated rendering-wise (physics and simulation may be a different matter depending on how accurate the underlying driving model is); you have basically a fixed perspective - the car follows the track at all times

Years ago (at least 16), I simply used an array to store the road segments. Testing if you're inside a segment isn't hard ofcourse, dot3 is your friend. So yes, not complicated at all=)

Yet, the game skips PS360?
 
Even if it was confirmed to be on a circa 2012 55nm engineering process, even if it wasn't TSMC or the other major foundries there should be an easy to make 47XX or 48XX based or related GPGPU there...its all up to devs to make customized games.

55nm is an iffy proposition, primarily because of the EDRAM density which is quite respectable even for the 28/32nm node. Nothing on 55nm is even close to that density. Another data point that has appeared since I made my last trawl through the net for density numbers is that Intel on their Iris Pro squeezes 128MB of EDRAM onto 70-80mm2 of 22nm die, which is in line with the data from TSMC/NEC-Renesas/IBM on higher nodes.

Also, the same article is quite clear in that the GPU is stronger than those of the HD-twins. Not only did it allow for effects to be added, but it also had some cycles left after that allowing the programmers the opportunity to consider moving calculations from the CPU to the GPU (which in the end they didn't). So, even in a straight port scenario, this particular testimony claims greater GPU performance, which implies an SPU density more in line with 40nm than 55nm.

Of course, process maturity and low clock targets may have allowed really good density results on 55nm, but personally I find it hard to credit given the extremes called for, Far easier to assume 40nm. (Not that it makes one whit of difference just how they get the density they do.)

Interesting to read that memory bandwidth needs were handled nicely by the EDRAM, even for a port. (At least for this particular game.) And again a confirmation that the CPU chokes on code "optimised for the PS360 CPUs" which in this context pretty much means cache resident SIMD code. The implication being that no SIMD units were added to the cores,

Overall, the article confirms all but extreme speculations. The only outlier being that 55nm quote, but that was also indicated to be "someone elses" opinion.
 
And Nintendo is already working on the next-gen Wii U ? Is this a desperate move or a part of a well planned execution ?

http://www.nintendonews.com/2014/01/nintendo-fusion-could-be-nintendos-next-gen-hardware-name/

Fusion DS sounds a bit confusing to me. The mobile GPU division of AMD was sold to Qualcomm... maybe it's just a Qualcomm mobile SoC ?

Fusion DS

CPU: ARMv8-A Cortex-A53 GPU: Custom Adreno 420-based AMD GPU
COM MEMORY: 3 GB LPDDR3 (2 GB Games, 1 GB OS)
2 130 mm DVGA (960 x 640) Capacitive Touchscreen
Slide Out Design with Custom Swivel Tilt Hinge
Upper Screen made of Gorilla Glass, Comes with Magnetic Cover
Low End Vibration for Gameplay and App Alerts
2 Motorized Circle Pads for Haptic Feedback
Thumbprint Security Scanner with Pulse Sensing Feedback
2 1mp Stereoptic Cameras
Multi-Array Microphone
A, B, X, Y, D-Pad, L, R, 1, 2 Buttons
3 Axis Tuning Fork Gyroscope, 3 Axis Accelerometer, Magnetometer
NFC Reader
3G Chip with GPS Location
Bluetooth v4.0 BLE Command Node used to Interface with Bluetooth Devices such as Cell Phones, Tablets
16 Gigabytes of Internal Flash Storage (Possible Future Unit With 32 Gigabytes)
Nintendo 3DS Cart Slot
SDHC “Holographic Enhanced” Card Slot up to 128 Gigabyte Limit
Mini USB I/O
3300 mAh Li-Ion battery

Fusion Terminal

GPGPU: Custom Radeon HD RX 200 GPU CODENAME LADY (2816 shaders @ 960 MHz, 4.60 TFLOP/s, Fillrates: 60.6 Gpixel/s, 170 Gtexel/s)
CPU: IBM 64-Bit Custom POWER 8-Based IBM 8-Core Processor CODENAME JUMPMAN (2.2 GHz, Shared 6 MB L4 cache)
Co-CPU: IBM PowerPC 750-based 1.24 GHz Tri-Core Co-Processor CODENAME HAMMER
MEMORY: 4 Gigabytes of Unified DDR4 SDRAM CODENAMED KONG, 2 GB DDR3 RAM @ 1600 MHz (12.8 GB/s) On Die CODENAMED BARREL
802.11 b/g/n Wireless
Bluetooth v4.0 BLE
2 USB 3.0
1 Coaxial Cable Input
1 CableCARD Slot
4 Custom Stream-Interface Nodes up to 4 Wii U GamePads
Versions with Disk Drive play Wii U Optical Disk (4 Layers Maximum), FUSION Holographic Versatile Disc (HVD) and Nintendo 3DS Card Slot
1 HDMI 2.0 1080p/4K Port
Dolby TrueHD 5.1 or 7.1 Surround Sound
Inductive Charging Surface for up to 4 FUSION DS or IC-Wii Remote Plus Controllers
Two versions: Disk Slot Version with 60 Gigs of Internal Flash Storage and Diskless Version with 300 Gigs of Internal Flash Storage
 
Never underestimate the internet's ability in an information vacuum to plain make shit up... :rolleyes:

I'd be highly surprised if a single word of that text is true, beyond that nintendo's undoubtedly looking at creating some form of new hardware.
 
Status
Not open for further replies.
Back
Top