By that same lack of
logic then every single console used a not tried and tested GPU. Afterall, no one but Microsoft used that exact GPU in Xbox One, and no one but Sony used that exact GPU in PS4. Repeat the same
logic for PS3, and X360, and WiiU, and Wii, and XBox Original, and PS2, and PSX, and ...
Maybe he meant tried and tested IHVs? Before the 3DS' design win somewhere in 2009/2010, DMP was AFAIK a start-up spin-off from academic beginnings.
With all the "tried and tested" options that Nintendo had at the time (nVidia, IMG, Broadcom, ARM, Vivante), no one saw DMP coming.
There are but unfortunately many are poor mobile ports - rather than Vita game being a port of the PS3/PS4 version, it'll get a bad port of the iOS/Android version. As a Vita owner I'm well aware many games have been announced but I'm very used to Vita ports being cancelled.
But the Vita does have an enormous portfolio in Japan.
Localize just one third of the japan-exclusive mecha games and JRPGs and consider me a happy man with the Vita for years to come.
Like wii u with their gpu and cpu tried and tested from wii tried and tested from GameCube.
The Wii U's GPU is "tried and tested" from AMD's Terascale GPUs for the PC market. AFAIK it has very little coming from the ArtX architecture that ended up in the Gamecube and Wii.
Nintendo should use 64bit ARM processors, Jaguar runs very close in performance with A57 and with the WSJ stating that Nintendo is using Industry leading chips, A72 is likely on the table, along with GCN2.
But does Jaguar/Puma consume as much as a Cortex A57 at the same sustained clocks?
This article tells me that in Exynos 7420 each Cortex A57 is consuming around 1.3W under full load at 2.1GHz. That's not a really low number if we're dealing with a handheld.
If you want sustainable performance with a low power consumption, your 64bit ARM options are either Cortex A53 or Cortex A35.
4 core A72 with 4 A53 cores + GCN2 /w 16CU @ 1ghz all on Samsung's 14nm process would be pretty nice. AMD is also releasing APUs this year with HBM, so it wouldn't surprise me if Nintendo went this route for reduced board complexity, also this all translate well to the handheld with fewer cores and lower clocks with 540p screen resolution.
I don't know how many times I've stated this in this thread...
big.LITTLE is made for "unpredictable"
peaks in a typical smartphone usage. What a console needs is high
sustained performance.
Using big.LITTLE in a console would be a waste of resources, unless the console maker was willing to force the game developers to distribute the workload manually between slow and fast cores.