AMD and ARM's new CPU/GPU virtual ISA | Hacker News Reader

AMD and ARM's new CPU/GPU virtual ISA

semiaccurate.com

81 pointsSymmetry26 comments

This is makes sense, esp with regards to the scalar core that is being included in the CU. Most likely that scalar core is ARM derived.

I made noises that AMD needed to remove 32 bit and SSE and just focus on OpenCL. What is being speculated actually reaches much farther than that and is a better design. Thanks for the clue stick.

Also more corroborating evidence, Anton Chernoff one of the main creators of FX!32 (http://en.wikipedia.org/wiki/FX!32) works for AMD Boston. FX!32 was/is one of the most badass dynamic recompilation engines I have ever witnessed. It could load X86 executables and effectively JIT them to Alpha. This is the kinda of technology needed to support a virtual ISA.

Anton Chernoff http://www.linkedin.com/pub/anton-chernoff/1/59/6b2

http://www.usenix.org/publications/library/proceedings/useni...

Holy crap, memory barriers! It's a modern architecture that's finally caught up to where Symbolics was at in the '80s. Seriously though, this is good news for concurrent garbage collected languages.

Barriers are slow, and the more cores are hitting the barrier the slower it will be. The best news on that front was from the new GPU architecture parts, where they admitted that they're still going to expose the relaxed consistency memory model.

"Barriers are slow" in what way? Azul was hitting 10-20ms pauses while successfully garbage collecting 500GB+ heaps using hardware memory barriers on their Vega architecture, which had up to 768 CPUs.

Cliff Click, Azul's principal JVM architect, seemed somewhat ambivalent about how much hardware transactional memory actually helped them hit those targets (i.e. it's not a silver bullet), but he chided Sun for not including it on their Niagra chips when they were providing both the language runtime and the hardware platform.

I'll say it again: Getting them on a commodity architecture is a great thing for concurrent garbage collected languages.

this is awesome. i had no idea anything like this was coming. is there anything out else out there that confirms this? and will it extend upwards to include bulldozer too?

You can find the whole main presentation here: http://developer.amd.com/documentation/presentations/assets/... I'm presuming stuff coming from amd.com is confirmation. It should certainly include future products, what I would worry about is to what extent existing graphics cards will be able to take advantage of this.

Generally, I'd say this looks a lot like Clang but with better ways to express memory parralelism at least. No way to know at this point to what extent this will catch on, but it looks interesting.

I think it's bigger than that - the idea that a GPU can execute syscalls is pretty crazy if you really buy into it (i.e. the entire OS is running using this heterogenous environment)

This is possible now [1]. FSA will (hopefully) make it significantly more efficient.

[1] http://www.idav.ucdavis.edu/publications/print_pub?pub_id=10...

The part where they mention graphics becoming pre-emptable kinda solves Microsoft's concerns about WebGL DOS attacks.

Wouldn't a virtual ISA be against the interests of hardware designers who benefit from ISA lockin?

Intel and NVidia want large piece of small pie

AMD and ARM want small piece of large pie

Even NVIDIA isn't crazy enough to try to get everyone to use the same ISA again; they're trying to get you to buy into their compiler chain, not into the architecture of a particular generation of GPU.

Is PTX really ISA? It's also virtual, but very limited ... Unlike PTX, FSAIL will work on both CPUs and GPUs and even will allow system calls from discrete GPUs.

PTX seems quite reasonable to me, but I don't think it's really intended to be a programmer-facing abstraction. NVIDIA wants you to target CUDA, and they'll (try to) ensure that CUDA has sufficient performance advantages to make it worth your while to do so.

It would but none of the players have the mindshare, capital or cred to do this. We are at a near perfect astable state in terms of competition. I am really stoked about all of this.

One word. Microsoft, if them AMD and ARM are onboard that's it. Remember nVidia is an ARM licensor/developer

AMD is definitely not on board with Microsoft taking over the scene. AMD is 100% behind standards, standards like OpenCL. Look at the way MS implemented their AMP C++ GPU story, http://herbsutter.com/2011/06/16/c-amp-keynote/ that looks to me like it targets and has all the limitations of DirectCompute (MS specific GPGPU). If MS really wants to make this a standard then most likely AMD will implement that standard using Open64 (http://www.open64.net/) and emit OpenCL kernels which will be handed off to their device specific OpenCL compilers.

I don't think MS has the power you give it credit for.

Think of it this way. OpenCL like OpenGL is an API that says you can build it however you want so long as it comply's with this standard. DirectX and DirectCompute are the same. Despite their vast architectural difference both AMD and nVidia GPU's work on them just fine, All FSAIL does is bring it all closer to the metal and encompasses the CPU as well, (instead of just GPU alone). You're telling me Microsoft (still OS marketshare leader) want's to split arch dev teams between x86,ARM or whatever else the future brings. They'll probably come up with their own version of FSAIL but I think they'd be stupid if they weren't on board (at least with their own version).

MS has money, which most people accept.

https://secure.wikimedia.org/wikipedia/en/wiki/File:AMD_K5_P...

btw: there is a story about a company committed to Open stuff (Linux, Qt), just to [d|b]itch it.

We are nearly in a post MS reality. It is like 1988 all over again. DR Dos, DESQview, GEOS they are all back in way with iOS, Android (which oddly enough is more Newton influenced than iOS).

The Win95 logo on a K5 doesn't bother me, Nokia doing really stupid stuff is indicative that they didn't have any solid competition for a great long while and went batshit insane. I had reports from Finnish friends that claimed that Nokia acted like they owned the whole damn country and make or break any law it pleased. When that kind of hubris implodes you best not be standing too close. They could have made a tidy sum selling well built yet simple Android powered phones to the worlds bottom 2 Billion People while attacking the verticals underserved by Nextel and Blackberry's gaffs. HTC owns the mainstream sexy-as-hell phone market. I would not try or want to compete with HTC.

AMD is above all this buffoonery, they are about to license their IP and throw it to the wind. And ARM might just end up managing the portfolio.

I hope I'm not the only one who finds this article poorly written; I got a better understanding from the list of bullet points on the slide than I did trying to follow the rambling paragraphs below them.

I wonder if Apple will use this with Grand Central?

It wouldn't be hard, except for Apple being in bed with Intel.

As they exist today, GCD/libdispatch blocks are very similar to OpenCL native kernels, but with more automatic scheduling and implicit data transfers (which are almost no-ops when the kernel is running on the host device).

On an AMD Fusion system with a shared memory controller, you don't have the huge latency of transferring your kernel arguments to the GPU (and with libdispatch blocks, you are generally transferring less data), so a block could be executed on the GPU with hardly any more overhead than on a different CPU core.

The only problem would be that you would need universal binaries of your blocks to also target the GPU (or LLVM IR to be finalized at runtime). As Apple has complete control over their very modern and flexible LLVM-based toolchain, implementing this would be very straightforward, even without the fruits of an AMD/ARM collaboration. (Though it sounds like ARM may help AMD be able to provide an array of scalar processors that would have good performance characteristics for typical dispatch_async uses.)

some damn convincing speculation, i must say.

Does this portability compromise performance at all?

It compromises performance in a similar way to using any byte code vs final machine code. It remains to see how much of a VM support will be required to make this work, as that's typically the large overhead cost of using non-machine code.

If anything the same exact FSAIL will run faster and faster on the same exact hardware as newer JITs come out.

Reply on news.ycombinator.com