The HSA Foundation released version 1.1 of their specification, which focuses on “multi-vendor” compatibility. In this case, multi-vendor doesn't refer to companies that refused to join the HSA Foundation, namely Intel and NVIDIA, but rather multiple types of vendors. Rather than aligning with AMD's focus on CPU-GPU interactions, HSA 1.1 includes digital signal processors (DSPs), field-programmable gate arrays (FPGAs), and other accelerators. I can see this being useful in several places, especially on mobile, where cameras, sound processors, and CPU cores, and a GPU regularly share video buffers.
That said, the specification also mentions “more efficient interoperation with non-HSA compliant devices”. I'm not quite sure what that specifically refers to, but it could be important to keep an eye on for future details — whether it is relevant for Intel and NVIDIA hardware (and so forth).
Charlie, down at SemiAccurate, notes that HSA 1.1 will run on all HSA 1.0-compliant hardware. This makes sense, but I can't see where this is explicitly mentioned in their press release. I'm guessing that Charlie was given some time on a conference call (or face-to-face) regarding this, but it's also possible that he may be mistaken. It's also possible that it is explicitly mentioned in the HSA Foundation's press blast and I just fail at reading comprehension.
If so, I'm sure that our comments will highlight my error.
Arm Holdings appears to be
Arm Holdings appears to be supporting Vulkan/OpenCL/SPIR-V more than the HSA foundation’s HSAIL, and ARM Holdings is a founding member of the HSA foundation. At least initally this AnandTech article(1) stated:
“From a software standpoint, it’s interesting to note that ARM has gone with an OpenCL 2.0-centric approach, intending to make the functionality accessible through that and related (SPIR-V utilizing) APIs such as Vulkan. G71 however does not support the Heterogeneous System Architecture’s HSAIL standard, this despite ARM being a member of the HSA Foundation. ARM did not have too much to say on the matter, but has stated that they never “totally bought into” HSAIL. OpenCL 2.0, by comparison, is a more generic implementation at the API level, leaving ARM to sort out the low level details as they see fit.”(1)
But this update was added to the article on 06/01:
“Update 06/01: With yesterday’s announcement of the HSA 1.1 specification, I went back to ARM to ask them whether the new specification impacts the company’s heterogenous compute plans at all, especially given that their architecture doesn’t support the 1.0 standard. As it turns out, ARM is going a route very similar to AMD’s ROCm platform: while the company isn’t utilizing the HSAIL – and thus in the strictest sense isn’t a complete HSA platform – they are using the HSA standard in the development of their hardware.”(1)
So what do you make of this, Scott, do you think that Khronos’ SPIR-V Duplicates the HSA foundation’s HSAIL in scope or is there room for both SPIR-V and HSAIL intermediate languages for HSA types of workloads?
(1)
“ARM Unveils Next Generation Bifrost GPU Architecture & Mali-G71: The New High-End Mali” (see Page 4 of the article: “Putting It Together: Mali-G71”)
http://www.anandtech.com/show/10375/arm-unveils-bifrost-and-mali-g71
It seems like the hardware
It seems like the hardware implementation and other parts of the standard are much more important than what language is used for the shader code. The main thing is the unified memory space in hardware and having the driver, OS, and user code set up such that it does not do unnecessary copying in HSA systems.
This just reinforces my
This just reinforces my opinion that AMD has done more to push the industry forward than just about any other company. Nvidia and Intel have held things back in an attempt to protect their profits.