Viability of a MIPS64/ARM64 based console?
- Thread starter Flux
- Start date
D
Deleted member 13524
Guest
I have no idea about MIPS, but I guess that if OUYA and/or Project Shield are successful enough, we'll have future iterations with nVidia's Parker (Tegra 6?), which includes a 64bit ARMv8 Denver CPU.
If I were to regurgitate what others more educated members stated (while looking at real world comparison between different arch based on different ISA), I would they that indeed those would be viable choices.
Actually having read talk on the matter many times it seems that the difference made by the ISA is pretty minimal once you blend in out of order execution (and other complex schemes). For example X86 was pretty low on the number of general purpose registers vs lots of RISK ISA (8 registers vs 32 in PPC for example) but with OoO execution and register renaming is not much of an issue.
Things got better for the X86 with the 64 bit extension which raise the number to 16.
(There are other details about those ISA, it is not only a matter GPR but I don't know the details well enough, if at all, what I read is that as the cores are getting more and more complex (and bigger) the ISA gets less and less relevant).
I guess for an IO processor, PPC, ARM v8 or MIPS 64 would be a better choice than X86-64 but I would not expect a massive difference either.
Overall putting X86 aside I would think the ARM v8 would be the better choice (especially for an IO processor) because of the size of the market and the traction that ISA has which means that it is likely to have good tools already and situation should get even better.
Actually having read talk on the matter many times it seems that the difference made by the ISA is pretty minimal once you blend in out of order execution (and other complex schemes). For example X86 was pretty low on the number of general purpose registers vs lots of RISK ISA (8 registers vs 32 in PPC for example) but with OoO execution and register renaming is not much of an issue.
Things got better for the X86 with the 64 bit extension which raise the number to 16.
(There are other details about those ISA, it is not only a matter GPR but I don't know the details well enough, if at all, what I read is that as the cores are getting more and more complex (and bigger) the ISA gets less and less relevant).
I guess for an IO processor, PPC, ARM v8 or MIPS 64 would be a better choice than X86-64 but I would not expect a massive difference either.
Overall putting X86 aside I would think the ARM v8 would be the better choice (especially for an IO processor) because of the size of the market and the traction that ISA has which means that it is likely to have good tools already and situation should get even better.
Last edited by a moderator:
PS3 and XBox 360, PSP, DS, and 3DS are in-order. Wii, Wii U, and Vita are out-of-order.
No. For up to date examples look at multi-core Atom and Cortex-A7 SoCs.
Here I will insert my usual disclaimer on this:
There's a huge continuum for how much instruction reordering a processor can do. In-order just happens to refer to zero reordering, while out-of-order refers to any quantity above zero (although sometimes people argue over what constitutes as reordering).
And, level of reordering is just one of many aspects of CPU design. PS3 and XBox 360 have CPUs that have problems extending far beyond lacking reordering.
anexanhume
Veteran
A MIPS64 console is really just saying "An ImgTec console" since they own MIPS now and arguably have the best mobile GPUs out there.
MIPS architecture is still licensed, like ARM.. I have no idea how many SoCs are using custom MIPS processors as opposed to IP cores bought from MIPS (or IMG like you say) but they're definitely out there.
anexanhume
Veteran
Let me re-word: I can't imagine a MIPS console that isn't a collaboration with ImgTec and features one of their GPUs. Kind of like how I can't imagine an x86 console from AMD that doesn't have their GPUs too.
That's like saying you couldn't imagine a console that uses an ARM CPU but doesn't include ARM Mali graphics. Which wouldn't make a lot of sense given how many other pieces of hardware don't follow this pairing. MIPS business model has always been to license out both the architecture and CPU core designs and IMG hasn't announced any intention of changing that. AMD on the other hand never had a business model where they license x86 CPUs and it's uncertain if their agreement with Intel even allows it. PS4 and Durango are said to be using AMD manufactured parts, not sure if that's true but if it is it of course means they had no realistic choice but to use AMD GPUs. Someone making an ARM or MIPS console would not be bound by these restrictions.
On the other hand, Ingenic (MIPS32 licensee, makes their own CPU cores for their SoCs) recently moved from Vivante to PowerVR after the acquisition, so there could have been some kind of licensing cost incentive involved. Or it could have been a coincidence.. a lot of SoC vendors are moving to IMG and Vivante's been losing some design wins..
"best" is... probably the wrong word. I'd say their GPUs are used by OEMs that have the largest silicon budgets like Apple and Samsung. I'm sure if Nvidia had the same die budget as those companies because they're guaranteed to sell hundreds of millions of units per year and the cost of the die is pretty miniscule compared to the BOM of a device, they'd have a far more competitive product. But when you're competing with Qualcomm who already integrates cellular basebands directly into their chips as a single package and every design win is a battle, it's a tough sell.
Hmm? IIRC Wii was in-order too, and OoOE was one of the improvements in Wii U's CPU?
From what we know the basic uarch of the CPU core (ignoring further out stuff like L2 cache and multicore interconnects) has not really changed from Gamecube to Wii to Wii U. It's PowerPC 750 derived which has mild OoOE.
I remember when Wii's CPU specs were first becoming known a lot of people were arguing that it'd make up for the huge difference in clock speed between it and PS3/XBox 360's CPU because it was out of order and they were in-order. Kind of funny to see the same sorts of people this time around say that Wii U's CPU has a big IPC boost over Wii's because they made it out of order
MIPS and ARM can do what a concole cpu needs. It just won't be a very powerful concole from the direction both architecture has progressed. Both are generally low power lower performance when compared to powerpc or x86. If someone wants to design a cpu from scratch based on the ISAs and add a few extensions, they can make a cpu just as powerful as an x86 one given it is used in a closed system like a console. Designing something like this isn't cheap. Its also likely to be a long process. It will probably have extremely low yield over the first few iterations. Few company can afford to do this and none would want to.
PS2s R5900 was an implementation of MIPS64 (customized - notably it ommited 64bit Mul/Div but made GPRs 128bit and added a bunch of 128bit operations).
Not entirely sure I understand the question though - the "RISC" ISAs aren't drasticaly different (they all got arbitrarily more complex over the years, but still follow similar paradigms) - it's really more a compiler problem once you get past the basics.
If this is the silly notion that ISA dictates performance, or even performance/watt - well I think there's a fair amount of recent "literature" online that disagrees.
Not entirely sure I understand the question though - the "RISC" ISAs aren't drasticaly different (they all got arbitrarily more complex over the years, but still follow similar paradigms) - it's really more a compiler problem once you get past the basics.
If this is the silly notion that ISA dictates performance, or even performance/watt - well I think there's a fair amount of recent "literature" online that disagrees.
I would say the newer ARM cores would do fine in a console, but they might need a bit better SIMD.
The PPC cores that every console has used have not been that crash hot.
