[hexus.net]AMD claims it will power another gaming device

[NTMBK]

K1 could be an interesting choice for a console. Single fixed hardware platform means the compiler could be finely tuned to extract maximum performance from the VLIW arch. Developers seem to prefer a straightforward out-of-order core with good branch prediction, though- fewer "tricks" and less ugly code required.

 

[TurtleCrusher]

K1 could be an interesting choice for a console. Single fixed hardware platform means the compiler could be finely tuned to extract maximum performance from the VLIW arch. Developers seem to prefer a straightforward out-of-order core with good branch prediction, though- fewer "tricks" and less ugly code required.

VLIW, isn't that what's used in my 6870? VLIW5? VLIW4 is what was in the 5xxx series IIRC... It's been a while since I've seen that term.

 

[Rezist]

I don't see Nintendo going anything but ARM going forward, I suspect in 5 years there won't be any x86 consoles, having Qualcomm, Apple, Samsung, AMD, and even nVidia all competing for your dollar sounds like a far better proposition then being stuck with AMD indefinitely. The real question is ARM ready in 5 years? As long as they start on higher wattage/more performance designs I think they will be ok.

 

[Rezist]

Ugh, the 3ds hardware is already poorly specced for handhelds. If Nintendo uses something like that in a console it'd be hideous....
A high end smartphone SOC would be a better fit. Performance wise, something like the Tegra K1 is in the same ball park as the Wii U (maybe better), so it's not like the performance for a reasonable console isn't there.



Tegra K1 shows that nvidia could have played that game with an ARM core, but they had no proven track record when Sony and MS were shopping, and are probably a little late to the game. They also aren't likely to be as cheap as AMD, and didn't already have ready to go solutions that could be produced at either GF or TSMC.

Yeah but could ARM cores be a viable alternative to the AMD cores? (Kabini or Jaguar or whatever there called)

It didn't really seem like it, but in 2016/2017 seems possible, also Nintendo is going to have trouble selling home consoles over 299$ moving forward, they need a cheap platform.

 

[monstercameron]

VLIW, isn't that what's used in my 6870? VLIW5? VLIW4 is what was in the 5xxx series IIRC... It's been a while since I've seen that term.

i believe vliw4 was 6950 and trinity apus.

 

[MisterLilBig]

There is a benefit for Nintendo staying with AMD, a familiar GPU architecture. ARM is already ready, it has everything that it needed when the new consoles where being designed, meaning, x86 could have never been on a console again if they had started not much time ago.

The soonest a new Nintendo next gen console will come out is Q42016 and in 2015 we will see 64bit ARM everywhere, from standard cores to custom ones.


There is one "player" that could be a major advantage to Nintendo also, if they do decide to drop AMD, Imagination, PowerVR with ARM64 cores or with MIPS64 cores.


I wouldn't trust NV with a SoC for my own product ever, just look how the TK1 Denver is lacking so many OpenGL extensions on the Nexus 9 compared to the TK1 A15 on the Shield Tablet. Same GPU, less features, older driver on a product 4 months newer.

 

[NTMBK]

VLIW was also used by Transmeta. It's just a general technique- AMD's VLIW5/4 was just one implementation of it.

 

[SPBHM]

i believe vliw4 was 6950 and trinity apus.

yes, "VLIW5" was for everything from HD 2000 up to HD 6800

HD 6900s and Trinity/Richland used "VLIW4",

the Wii U is also "VLIW5" as far as I know

 

[Fox5]

Yeah but could ARM cores be a viable alternative to the AMD cores? (Kabini or Jaguar or whatever there called)

It didn't really seem like it, but in 2016/2017 seems possible, also Nintendo is going to have trouble selling home consoles over 299$ moving forward, they need a cheap platform.

Jaguar is pretty weak, the high end ARM cores are all at least in the same ballpark.

Nvidia was probably the only legit competition in this space though, and 64-bit was probably a requirement given the 8GB of memory in the consoles. That means Denver would be the only viable ARM core, and it launched too late. Perhaps the launch window could have been moved up, but it was a completely unknown design.

AMD is launching ARM cores though, so they could provide that for Nintendo. They should be cheap too, given that there were rumors of a $200 server ARM based server platform from AMD.

 

[Tuna-Fish]

K1 could be an interesting choice for a console. Single fixed hardware platform means the compiler could be finely tuned to extract maximum performance from the VLIW arch.

Even today, to get most out of a VLIW you need to work in assembler. Compilers are better than they used to be, but the main upside for VLIW is in finely hand-tuned code.

Developers seem to prefer a straightforward out-of-order core with good branch prediction, though- fewer "tricks" and less ugly code required.

That's one half of it. It's not all of it. No matter how fine your compiler, OoO hardware can generally extract more memory-level parallelism of the code than any static optimization. In contrast, for constant-latency operations static optimization is better than OoO, due to much larger "instruction window". This means that as the proportion of non-stream memory ops in your code grows, the worse VLIW gets for it. Games like lots and lots of large complex memory structures -- these are a bad fit for VLIW.

VLIW was also used by Transmeta. It's just a general technique- AMD's VLIW5/4 was just one implementation of it.

VLIW is today mostly used in digital signal processors and the like, where they dominate the field. The demands of that segment is basically a checklist of things that are good for VLIW.

• Low power
• Low silicon budgets
• High alu op workload
• Memory access is typically cleanly streamed
• Total code size that is run on the device is very low, making hand-optimization sensible

Mobile devices are an interesting target for Denver because so much of the code that runs on handsets is already jit-compiled javascript. Right now this is bad for Denver because there is no js-to-Denver compiler, on js benchmarks they run two jit compilers after each other. I'd assume that a js to Denver native jit compiler is pretty high on nVidia's priorities, as it would mitigate much of the disadvantage they have versus native ARM cpus.