Heterogeneous compute has been on the tip of the tongue for many involved in integrating compute platforms, and despite talk and demos regarding hardware conforming to HSA provisional specifications, today the HSA Foundation is officially launching the ratified 1.0 Final version of the standardized platform design. This brings together a collection of elements:

- the HSA Specification 1.0 defines the operation of the hardware,
- the HSA Programmers’ Reference Manual for the software ecosystem targeting tools and compiler developers,
- the HSA Runtime Specification for how software should interact with HSA-capable hardware

The specifications are designed to be hardware agnostic as you would imagine, allowing ARM, x86, MIPS and other ISAs to take advantage of the HSA standard as long as it conforms to the specifications. The HSA Foundation is currently working on conformance tests, with the first set of testing tools to be ready within a few months. The goal is to have the HSA specification enabled on a variety of common programming languages, such as C/C++, OpenMP, Python as well as C/Fortran wrappers for the HPC space. Companies such as MultiCoreWare are currently helping develop some of these compilers for AMD, for example.

The announcement today is part of an event being held in San Jose, CA, and the event will also see the preview of a HSA book designed to help developers in this space. There will also be a round-table panel of HSA board members discussing the release as well as taking questions. Some of the obvious key points the HSA Foundation will be pushing include video conferencing in mobile (exchanging encode cycles on the CPU/GPU for lower bandwidth requirements), video search, embedded applications and high performance computing, especially those with high memory requirements but can still take advantage of co-processor based compute.

As part of the pre-briefing we received, Phil Rogers, the president of the HSA Foundation and corporate fellow at AMD, explained the purpose of the announcement and answered a few of our questions. Mr Rogers explained how current Kaveri APUs currently rely on the HSA 1.0 Provisional specification, and Carrizo (based on Excavator) will aim for 1.0 Final compliance if the tools are ready before Carrizo launch. Carrizo will not be held back in order to secure compliance before ramping up production, but the expectation is that it should pass and be used similar to Kaveri but with the minor adjustments required for 1.0 Final, such as GPU context switching.

Mr Rogers also explained that the HSA 1.0 Final specifications should integrate with Aparapi for Java and Project Sumatra, both of which we described back at Kaveri launch last year. Currently C++ AMP is also a goal as it allows a reduction in defining restricted kernels due to the unified memory. Also making sure that the new upcoming version of C++17 is also fully supported within the HSA context is important.

With regards profiling, the HSA Foundation has a Tools Working Group currently pursuing both a Profiling API and a Debugging API to allow low language software developers to integrate these tools into their GUIs. We were told that this should happen within a year, but the API requires proper low level access from the developer.

Mr Rogers was not able to comment on the implementations of other HSA Foundation members, particularly companies such as Qualcomm, Samsung, ARM, Imagination Technologies, LG and MediaTek, all of which have ‘arms’ into the smartphone space where HSA could encompass a wide variety of scenarios. We were told however that each of the members of the HSA Foundation, of which there are over 40 technology companies and 17 universities, were keen on closing the specification in order to move forward with their goals.

Heterogeneous System Architecture is in for the long haul for sure, although execution and improvement of user experience will be the key factors in providing something tangible. There also requires an element of learning to think in the HSA paradigm, something not specifically taught to young software developers entering college and university. To that extent, PCIe co-processors and multi-core programming are still low down on the list of to-teach. Nevertheless, I would imagine HSA offers a wide opportunity to those who can take advantage of it, developing their hardware and tools to use it effectively, and the ratification of the 1.0 Final specifications is a big step along that road.

Source: HSA Foundation

 

Comments Locked

24 Comments

View All Comments

  • Oniguma - Tuesday, March 17, 2015 - link

    You're fabricating a problem that doesn't exist.

    The squared circle aka squircle is that they use their GPU development in power consumption, performance and HBM VRAM that are directly integrated from discrete GPU development, over to APU development.

    The two products serve two different needs. While having similar development goals.

    What we really need to see is the IPC on AMD's X86 become competitive against Intel in their APU's. Otherwise all the integrated GPU power in the world won't mean anything in the desktop space.
  • R3MF - Tuesday, March 17, 2015 - link

    seems pretty inefficient, in that the enormous R&D resource they direct towards high-end GPU's does not complement the R&D resource they put into HSA.
  • pTmdfx - Tuesday, March 17, 2015 - link

    If you have gone through the specification, you might actually find the HSA specification *supports* accelerators with its local memory - the memory model, memory management API and the platform topology specification. One of the examples given in the specification even has discrete GPU nodes illustrated.

    Theoretically, discrete GPUs since Sea Islands should be able to support HSA to some degree (Base Profile, perhaps). It should be able to access system coherent memory via PCIe, and can handle system address translation via ATS/PRI backed by the IOMMUv2. The only thing left is probably whether or not AMD will enable the software for it.
  • pTmdfx - Tuesday, March 17, 2015 - link

    Okay, a correction: It is *likely* able to access system coherent memory via PCIe.
  • R3MF - Tuesday, March 17, 2015 - link

    cheers.

    via IOMMU would be interesting, but where doews this leave people with £500 AMD GPU's and an Intel Platform...

    if AMD made a platform worthy of a £500 GPU (or even a £300 GPU), then this wouldn't be a problem, but they don't.
  • pTmdfx - Tuesday, March 17, 2015 - link

    Perhaps someday. It is not all about AMD's own effort, but Intel's platform has to have the platform features for PCIe peripherals that are required by the whole HSA specification. Well... I know some of the boxes are checked, but I'm not sure if it does work. Still at least discrete GPU supports OpenCL 2.0.

    Frankly, HSA is for APUs in the first place, as HSA is to leverage the advantage of integration. Not a huge problem anyway, as you can probably expect HSA is more of an optimised path, where OpenCL 2 or similar is the baseline target. The feature parity in graphics is also the unaffected.
  • dahippo - Wednesday, March 18, 2015 - link

    My understanding is that IoT will be a big winner using HSA. You can put any accelerator on and use same memory and cache to keep size and power low.
  • Selim Reza - Monday, October 22, 2018 - link

    HSA Foundation engineering works with upstream projects on a set of requirements that are determined by the Technical Steering Committee.

    CatLight is a notification app for developers. It shows the current status of continuous delivery, tasks, and bugs in the project and informs when attention is needed.
    Checkout the page: https://catlight.io/home/sitemap

Log in

Don't have an account? Sign up now