AMD updates driver and programming tools roadmap for supporting HSA features in Kaveriby Rahul Garg on March 3, 2014 8:30 AM EST
In our Kaveri review, we discussed HSA and that Kaveri brings many exciting hardware features such as true CPU/GPU shared memory (hUMA) and others such as heterogeneous queueing (hQ). However, at launch they were not really exposed in the drivers. AMD has now provided an update on the driver roadmap for exposing the hardware features to various compute APIs.
Today AMD is expected to release a beta driver for Windows that exposes some shared memory extensions to OpenCL. Currently, AMD ships an OpenCL 1.2 implementation for Kaveri. OpenCL 1.2 standard by itself does not really expose shared memory features properly but OpenCL 2.0 will have more robust support. AMD does not have a full OpenCL 2.0 driver yet, but today they will be providing some of the 2.0 functionality as extensions in their current OpenCL 1.2 driver. I don't have the details on the exact extensions supported, and I will update the article when I do.
However, OpenCL is only part of the story. Kaveri's promise is that it will provide driver support for HSA software stack which includes components such as a compiler for HSAIL and a HSA runtime. HSA software stack will enable high-level languages and simplified programming models and the exciting HSA developments appear to be happening on Linux first. In Q2 2014, AMD will release a beta HSA software stack for Linux. The Linux HSA stack release will be around the same time as release of Berlin APU for servers and Bald Eagle APU for embedded applications. These are both variations of Kaveri for different markets and in both of these markets Linux plays a very important role.
The HSA runtime stack for Linux will enable compiler writers and low-level library developers to start developing for HSA. The official HSA runtime API specifications are not finalized yet, and this release will be based upon prototype specifications. However, I think the prototype driver will be close enough to the final specifications that it will not matter much to developers.
Most developers are not interested in the base HSA stack and instead will prefer higher-level languages and tools. Several programming languages and tools will be released this year for targeting HSA. First, AMD will release an HSA-enabled version of their Java Aparapi library. Currently Aparapi targets OpenCL 1.2 for all OpenCL capable systems, and the mentioned release will include optimizations specific to HSA enabled systems. The HSA-enabled release of Aparapi is already under development and testing and should be released soon after the HSA stack release.
At some point this year, Multicoreware is expected to release the HSA backend for their C++ AMP implementation for Linux. Finally, AMD also mentioned that an extension of GCC is being worked on with SUSE that compiles C/C++/Fortran OpenMP code to generate code for HSA. I am not sure about the version of GCC and the version of OpenMP supported, or whether this will depend on non-standard directives and I will update the article if I get this information.
To summarize, AMD is continuing to work on exposing Kaveri's differentiating hardware features such as hUMA and hQ to various programming languages and tools. This year we should see the HSA stack and associated tools and languages stabilizing and becoming very usable for Linux developers, especially for server and embedded markets. For Windows, at least applications using OpenCL will be able to tap into some of Kaveri's new hardware features and more options should be coming down the pipeline.
UPDATE: The new Windows driver with preview support for some OpenCL 2.0 type functionality is now downloadable from here. The driver has very specific hardware requirements, such as requiring a A10-7850K in an Asus A88X-PRO motherboard and 8GB of RAM. More details about the requirements and the OpenCL extensions supported can be found in the OpenCL 2.0 preview driver download.
Post Your CommentPlease log in or sign up to comment.
View All Comments
fteoath64 - Monday, March 3, 2014 - linkAs I suspected, Linux will get the HSA stack and compiler tools first. There is little incentive for MicroSoft to do much since Intel is not supporting HSA (as yet or if ever). But server apps will surely benefit hugely from HSA. As to the development of OpenCL 2.0, the pace depends on niche players like Altera, AMD and kronos group members. AMD has to champion the HSA runtime themselves for Kaveri. It seems like a couple of quarters away at best.
Klimax - Tuesday, March 4, 2014 - linkVendor specific stacks are rarely pushed by Microsoft, that's up to vendor themselves.
Note: Intel supports properly OpenCL and HSA-like apps (CPU+GPU) are running very well...
I doubt HSA will do any good to AMD...
przemo_li - Tuesday, March 4, 2014 - linkhUMA alone is great boost to everything. Other unified ways of doing things only make HSA-stack more atractive.
And HSA spread development costs.
PS HSA is no about CPU+GPU, its about making that difference go away. OpenCL is side addition to HSA. (Development in similar direction?)
DanNeely - Monday, March 3, 2014 - linkThis reads like a press release not an article, and has no business on the front page.
A5 - Monday, March 3, 2014 - linkPipeline has been around for a few years now. Have you just never read it before?
DanNeely - Monday, March 3, 2014 - linkI've been reading it for years. Normally it reads as a short news piece. Since AMD bought custom branding for a stream of its contents, I've felt that the pipeline items that appear from AMD Center have been below average quality; but this is a farce and a disgrace.
HisDivineOrder - Thursday, March 6, 2014 - linkMy take as well.
Homeles - Monday, March 3, 2014 - linkPipeline has nothing to do with this.
DanNeely - Monday, March 3, 2014 - linkOn the home page, this stinker is displayed with the other pipeline stories.
Homeles - Tuesday, March 4, 2014 - linkWhat I'm saying is that the fact that this is a Pipleline article is irrelevant. It doesn't matter where it's posted.
I think you're being a bit harsh, but I do see what you're saying.