palladin9479 :
People here have been throwing marketing terms around and all it did was muddy the waters. "HSA" isn't a processor type, it's just a set of standards that allow two non-uniform (as in their not the same type of processor) processors to cohabit the same real estate and communicate with each other without requiring expensive glue circuitry. "HUMA" is just the acronym invented to say that the GPU will use the same physical address map as the primary CPU. HUMA is part of the "HSA" concept / standard. This will allow vector instructions (SIMD basically) to be rapidly processed by the iGPU without needing them to be packaged and shipped off in the manor that OpenCL / GPGPU does. It reduces latency and the overhead required when doing this.
First HSA programmers reference manual is out (pdf in)
http://hsafoundation.com/standards/
Its a JIT approach alright, but with a dynamic runtime well suited for flexible apps... that wiil have several code paths attending the resources available
http://hsafoundation.com/hsa-programer-reference-the-formation-of-the-new-specification/
That will have its
Hardware platform specification to (which will be minimal i think) and is basically 4 definitions or items.
In Development
HSA Platform Systems Architecture Specification
version 1.0 – In the working group
*includes IOMMU v2.5 official standard
* most probably will include hUMA (*cache coherency* + IOMMU makes hUMA, like cache coherency + same MMU/TLB makes NUMA)
*includes hardware task queues visible from userspace.
HSA Programmer’s Reference Manual: HSAIL Virtual ISA and Programming Model, Compiler Writer’s Guide, and Object Format (BRIG)
0.95 - Up for ratification in the Board of Directors
1.0 In working group
HSA System Runtime Specification
Draft Specification in working group for development
HSA Tools
LLVM to HSAIL Compiler
HSAIL Assembler
So its mostly "software" alright but there is a
Hardware platform specification, not a processor uarch definition. That hardware definition is exactly what is needed for making diverse "processor element uarchs" act like an unified entity. Based that the gluing *magic* will be HSAIL not abstraction APIs. It will be more low level it will be considerably more flexible, allowing software developers to innovate. And hardly will be only about GPU, otherwise no TI or other DSP implementer will be there.
palladin9479 :
This will not directly speed up a dGPU in any sense but what it can do is allow the video game to offload physics and AI calculated to the iGPU while using the dGPU just for rendering.
That is exactly what it can do. The runtime environment(+ drivers) will be king saying where any piece of code runs, not the developer, that will code "exactly" has if everything is an single processor. It could be grand for beefing up tremendously the FPU parts in CPUs (XOP, AVX and or NEON) and start using ray-tracing more extensively (probably mixed with raster... and Imagination already has good ray-tracing boards based on ARM and their PowerVR)
palladin9479 :
For everyone else, please read up on what NUMA is and it's role in the multiprocessing world. "HUMA" is just the inverse of NUMA, multiple processors sharing the same physical memory space vs each having their own dedicated memory space.
Skewed exactly to the contrary. In NUMA the MMU/TLB part of the processing elements must be identical for not saying the same. In hUMA those MMU/TLB parts can diverge(edt), but they must adhere to the IOMMU standard. NUMA also presupposes that several DRAM pools are physically apart, and while that is true, there could be NUMA assigning unganged DRAM channels to different processor elements, only doesn't make much sense.
hUMA presupposes that there is only 1 DRAM pool, though this is the most straightforward, that is not necessarily true if there is *IOMMU complaint* and *cache coherency* over some interconnect for disparate "processing elements". And there could be several topologies, not only different boards over interconnect(like PCIe boards, but the problem is PCIe doesn't allow cache coherency... but Hypertrasnport and their HTX slots can, start to see intel cold sweats, and nvidia smell of rotten lol ? (edt) ), but also soldered to a PCB, inside a socket like MCM parts, or even 2.5/3D interposed.
[UPDATE 1 : and its not only Hypertransport (though this is what could impact more the game part of PC world, intel could have identical now if there were QPI slots), ARM AMB interconnect allows cache coherency over subtract, and even PoP (package on package) or 2.5/3D interposed parts... start to see the interest of ARM ? ]
[UPDATE 2 : any interconnect and the cache coherency mechanism "internals", is not and will not ever be part of any HSA standard... there is no need to... the only that matters is that is cache coherent and that it can work with the IOMMU guide lines ]