Bifrost brings ARM GPUs into the modern era

Quizzical

Apparently they've had enough of pushing GPUs that are architecturally inferior to what AMD and Nvidia had in 2007.  Bifrost is still targeted at the low power space, so I really doubt that AMD or Nvidia have anything to worry about from ARM in laptops, let alone gaming desktops.  But for mobile game designers to not have to worry about how some ancient architecture will handle their code is going to be a good thing.

Probably the most significant change is moving from a VLIW architecture (like AMD had from 2007-2011) to a modern one that relies much more on thread-level parallelism.  But there are a lot of other changes, and ARM is going to support Vulkan and OpenCL 2.0, among other things.  I'm sure they'll continue to support the less sophisticated OpenGL ES and other APIs that they've previously supported.

If you want to read more:

http://www.anandtech.com/show/10375/arm-unveils-bifrost-and-mali-g71

Your move, Qualcomm.

13lake

The most interesting part in the article is ARM saying "we weren't that into HSAIL anyway "

They seem ready to drop HSA support completely.

Quizzical

What's the point of HSA, anyway?  Does it give you anything that OpenCL, Vulkan, and OpenGL ES all don't?  Or is it just another entry in the stupid but long-running vendor competition to make Hello World easier, even at the expense of making basically everything else harder?

13lake

You would know better than me, you wrote a topic about it a while back when  AMD's K12 predecessor core was going to come late 2015-2016 (or even earlier, i don't remember exactly), and if i'm not remembering wrong HSA was supposed to bridge the gap between arm and x86 or something like that.
I distinctly remember it sounded like an impossible task to pull out properly and sounding like a needlessly forced attempt to break into the mobile market, like Nvidia's completely foolhardy attempt attempt to similarly break into mobile with Tegra.

On top if im not wrong that specialized processor family was canned and K12 was the pure arm64 successor while being quite late itself.

I sincerely don't understand how the people at all companies don't understand that once u have someone set in like Apple, you can't copy them, and similarly once you have the complete horizontal implementation dominance like ARM, again you can't brute force your way in like that either, ...

Quizzical

But that's just it.  OpenCL, Vulkan, and OpenGL ES don't care if you're using x86, ARM, or for that matter, MIPS or Power.  Anyone who wants to support it can support it.  That's the point of industry standards.  And we don't need 17 industry standard APIs that do the same thing; you should only make a new API if there's something wrong with the old ones.

I don't see a hole for a new GPU programming API to fill that the current ones don't already handle well.  There is perhaps the "make it easy for novice GPU programmers to write good GPU code without having any clue what they're doing" approach that various vendors would like to claim they offer (OpenACC, Nvidia CUDA, AMD Boltzmann, Microsoft C++ AMP, etc.), but that's impossible.

13lake

Wasn't the end goal of HSA to have both ARM and x86 cores on the same die(or even chip), and not just to be a architecture agnostic software ?

And for them to work in perfect harmony complementing each other with maximum utilization, with the goal to add a gpu part afterwards, and make some impossible perfectly scalable APU solution ?

Quizzical

13lake said:

Wasn't the end goal of HSA to have both ARM and x86 cores on the same die(or even chip), and not just to be a architecture agnostic software ?

And for them to work in perfect harmony complementing each other with maximum utilization, with the goal to add a gpu part afterwards, and make some impossible perfectly scalable APU solution ?

First of all, a "die" is the same thing as a "chip".  The former is a more technical term, and the latter more colloquial.  You can have multiple dies in the same package, in a "multi-chip module", but that's multiple dies/chips.

Having both ARM and x86 CPU cores on the same chip doesn't work the way you might imagine.  You're not going to present them both to the operating system and let it bounce code back and forth between them.  Even if you can compile the same source code separately for x86 and ARM, ARM cores can't handle a binary compiled for x86 and vice versa.  You could make cores of one architecture the "real" CPU that the OS talks to, and cores of the other into an accelerator like a GPU that the OS can't see the internal details of, but that's a very strange thing to do for performance reasons.

AMD actually does put an ARM core in some x86 server chips, but it's as a security co-processor.  The OS can't see the ARM core, and the idea is that if malware is trying to interfere with security processing, it will have a harder time getting the ARM core to do malicious things.  This isn't an advantage of ARM over x86; it's an advantage of a core that the OS can't see and do arbitrary things with over one that it can.  AMD could have designed their own very low power CPU core for this if so inclined, but presumably found it cheaper to just pay ARM a few pennies per die they make to license an ARM Cortex A4 or whatever it was they used.

HSA = Heterogeneous System Architecture, with the heterogeneous generally meaning a CPU and something that isn't a CPU but can still execute code.  The best known consumer products tend to have the "something else" be a GPU, but it could be an FPGA or some other things.

If you want to have write a program that runs code on both a CPU and GPU, and you aren't doing graphics, OpenCL is probably what you want to use.  That's pretty much a solved problem at this point up to minor tinkering in new versions.  HSA claims to be compatible with various other APIs, so I'm not clear on what HSA actually is itself.  You could use something else instead of OpenCL to run code on both a CPU and an FPGA, though with Altera and Xilinx now both pushing OpenCL for FPGAs, you can use OpenCL there, too.  And obviously, if you are doing graphics, you want a graphics API.

Quizzical

Upon further thought, I'm going to back off of the "CPUs and other stuff".  HSA might just be about CPUs and GPUs and nothing else.  OpenCL is very much interested in other stuff, but HSA seems to be AMD's baby, and all AMD has is CPUs and GPUs.  With neither Altera nor Xilinx nor IBM involved, it's probably just CPUs and GPUs.