I don't understand how that would work. You don't do such things for multi-threaded programming on a CPU. Yeah, you could theoretically trigger an interrupt on the GPU and interrupt whatever it's doing to have it switch to running the new function you're calling, but what if it was already running a function called by another CPU thread?
I'm fuzzy on the details, most likely because it never became a practical reality.
But my understanding was that quite literally it worked via an alternate interpretation of all instruction encodings and the APU would flip between an x86 and a "GPGPU" ISA on calls, jumps or returns.
Since all caches, page tables and even memory consistency semantics were shared between the two within the very same chip, the overhead of switching was absolutely negligible, nothing nearly as expensive as an interrupt, user/kernel mode or process switch, which is what I believe you have to do for ARM64/32/Thumb ISA or on x86/AMD64 transitions.
And by that it became quite obvious that it wouldn't do much good with discrete GPUs, even of both were to come from AMD, as they rarely shared the same memory space and even with an Infinity Fabric HBM/GDDRx/DRAM bandwidth and latency gaps would quickly destroy the value of such a super-tight HSA.
However, it might have been usable on consoles with AMD SoCs, so who knows?
Of course that would have also meant quite a bit of OS support, because the GPU side most likely had a pretty large register file, but then we've had process switch nightmares on x86 for a long time, starting with the venerable 8087.
Just like we do for multi-threaded programming on CPUs, I think a GPU API will always be buffer-based. The key thing is that the GPU be cache-coherent, and that's what saves you having to do cache flushes. It lets you communicate through L3, just like you would between CPU threads.
Buffer based, yes, but generally without having to copy and flush, instead doing user-to-remote-user-space rUDMA and messsage passing control transfers across large Infiniband or CXL fabrics. Perhaps even a bit of NV-link, but that doesn't scale to the tens of thousands of systems now used for GPT4 and beyond.
With such a base, the type of ISA switch HSA was supposed to do could still be done and as long as the architecture is GPGPU first and CPU second, it could be as efficient as it can be. There is this trend somewhat inspired by RISC-V, that general purpose ISAs are really just there for some legacy bootstrapping and general admin stuff, which is why Nvidia's Grace and Hopper are designed to really mesh the memory spaces, Tenstorrent and otheres make the CPU little more than a service processor.
I had the same idea, though I was more interested in OpenCL than HSA. Fortunately, I never got around to ordering it, though I think I got as far as spec'ing out all the parts.
100 W at the wall, or CPU self-reported? I'm impressed it was able to match a Skylake, at all. The fact that you compared it against a mobile CPU meant both that the Skylake had an efficiency advantage (due to lower clocks), but also a decent performance penalty.
Mostly self reported but also checked at the wall. And yes, the 22nm Intel Skylake process using 2 cores and SMT at 3.1 GHz was able to match almost exactly 4 AMD Integer cores (with 2 shared FPUs) at 4 GHz on 28nm GF.
But more importantly the 48EU Iris 550 with 64MB of eDRAM met the performance of the A10-7850 K Kavery 512 "core" iGPU up to a hair (which I had given the single rank of DDR3-2400 it needed for each of the two channels to get peak performance), burning much less energy (Intel iGPU always tend to get precedence, but they never get a lot of juice).
And I think the i5 actually had something like DDR3-1600...
It was really uncanny, how closely they matched in nearly every benchmark out there and please believe me that I tried a lot! That and a Phenom II x6 threw me off AMD after a long love affair that had started with a 100MHz Am486 DX4-100, I think, and lasted many generations (I came back for Zen3).
That chip was a design made just for Apple, most likely horrendously expensive to make as the iGPU was bigger than the CPU cores and mounting the eDRAM probably wasn't cheap, either.
But Apple lost its faith in Intel at this very specific point, evidently because there were daily errata and they expected better yet. So when they were eventually left over they were silently sold off in bulk and cheap to empty the warehouses. I got mine in a cheap Medion notebook and it's still running strong.
Not really. CPU cores are never as efficient as GPU cores, for a whole host of reasons.
AMX is an interesting case, but that's really just a special-purpose matrix-multiply engine that Intel bolted on. Oh, and the contents of its tile registers can't be accessed directly by the CPU - the go to/from memory. So, even with AMX, you're still communicating data via memory, even if the actual commands take the form of CPU instructions.
There are *so many* really interesting memory mapped architectures out there, both historically and even relativley recent, which act like memory to ordinary CPUs whilst they compute internally. The first I remember were Weitek 1167 math co-processors, which were actually designed ISA independent (and supposed to also work with SPARC CPUs, I believe). You'd fill the register file writing to one 64K memory segment (typically on an 80386) and then give it instructions by writing bits to another segment. You could then get results by reading from the register file segment.
A few years ago Micron had an architecture where you'd code non-deterministic finite state machines in a similar manner and send them data to process by writing to what seemed like RAM, collecting the computing results elsewhere. They called it the the Automata Memory Processor (
https://www.researchgate.net/publication/310821021_An_overview_of_micron's_automata_processor) and hoped to overcome the memory barrier that way.
There is also a French company called UPMEM, which has been in startup for what seems like decades now, ever quite getting off the ground.
Facebook
Twitter
Instagram