Except, the future is fusion.
It's the next step after multithreaded hardware.
For embedded devices. Where space is a premium beyond dies. What do you think has better yields. 2 100mm2 dies or 1 200mm2 die?
Enterprise and desktop doesn't have that issue. You can easily have an add-in GPU.
For something like competing with ARM in phone/tablets, sure, HSA would be nice...but even with Intel subsidizing 14nm parts its behind ARM. AMD is on 28nm. Neither stands a chance.
It's why Intel is devoting more then half of their die to the GPU and using eDRAM as a shared cache between CPU and GPU.
Intel is pushing forward into mobile and bolstering where they're currently weakest (lowest hanging fruit, iGPUs are horrendously bandwidth starved). That is only for mobile and desktop parts, and high end ones at that (Iris Pro). Broadwell Xeons don't have that eDRAM. IE Xeon D 1540.
By the way, Xeon Phi. In Enterprise Intel is moving in the exact OPPOSITE direction of HSA. Even GPUs they're moving away from there.
It's why the Qualcomm (an HSA founding member) Snapdragon 820, a mobile heterogenous SoC, is already being tested and will be in use by more then 30 different phones and tablets.
Yes, because it's an embedded device. Where space is at a premium. As is battery life and performance.
SoCs and embedded devices have been integrating since the first ARM smartphones, none of this is news. Qualcomm bought the mobile Radeon division off of AMD for integration of GPUs in the firadoption.
HSA compliant code is only marginally different then non-HSA compliant code.
"Hi, I'm not a programmer, and I don't know how much extra work it is to initially support a new compiler system and then debug for it years done the line."
And if you develop with HSA in mind, is only going to be easier to compile it back and forth for HSA and non-HSA compliant hardware.
Which people would do why? HSA compliant x86 hardware is what percentage of marketshare? 5% maybe? ~0% in servers?
Intel couldn't even force this without tossing around large amounts of money. Intel couldn't get people to support new instructions without tossing around cash. Supporting a new compiler system for special hardware? Hah! Fat chance.
In early testing before there was a 1.0 spec, HSA was more than twice as fast and used 2.5 times less power then OpenCL applications.
Marketing numbers != real world improvement. Those were absolutely ideal test scenarios.
GPGPU is only half the story.
GPU is the entire story. If it doesn't involve rendering or GPGPU there is no need for HSA. The entire point of it is to expose the iGPU as a latency-penalty free processor.
It's specific algorithms that are just better suited for specific kinds of processors already in a system. And the best way to do that, is to have a coherent shared memory system that doesn't have to write, and dump, and re-write, it's only read once, write once.
Which is nice from a latency perspective but an iGPU, even if they weren't crippled by memory bandwidth and that whole much larger die for integration introducing costs due to yields, operates a magnitude lower in performance than a high end GPU. And much worse than even cheapo GPUs.
Outside embeddeds, HSA isn't about to take off. And even there, AMD doesn't have the marketshare or cash to force adoption.