AMD has a rich history of innovation, being the first semiconductor company to produce a processor running at 1GHz, the first to bring 64-bit computing to the masses and true dual, quad, eight and 16-core x86 processors. AMD saw the potential of using the GPU for computation long before others and put it on the same piece of silicon as the CPU, creating the Accelerated Processing Unit (APU).

Much like AMD’s rich history in CPU design, the AMD Radeon™ GPU that is found in many of AMD’s products have a stellar pedigree that goes back more than 15 years and is known for high performance and energy efficiency. Since 2011, the GPU found in the AMD A-Series APU has provided the ability to play the latest games and provide access to considerable processing power thanks to OpenCL™ support.

The GPU has unquestionable computational potential and OpenCL provided developers with a way to tap the resource. However, AMD wanted to make GPU compute accessible to a wider audience, one that perhaps has not been brought up to speed on GPU programming and the intricacies of architectural differences between a CPU and GPU. This is one of the reasons why AMD has been working on the revolutionary Heterogeneous System Architecture (HSA).

HSA brings a suite of technologies such as Heterogeneous Unified Memory Access (hUMA) and Heterogeneous Queuing (hQ) to the developer that makes the GPU easier to program by bringing support for existing high-level programming languages through adding support for memory pointers and flexible multi-tasking, just like existing CPU programming. At the same time, HSA increases performance by eliminating the need to copy data between the CPU and GPU and by reducing task dispatching overhead.

With hUMA the GPU has access to the system memory, meaning the GPU can access very large datasets without the need for complex programming, and gives programmers the ability to use memory pointers just like when programming in C. While hUMA allows the GPU to be fed with more data than ever before, hQ allows the GPU to stand alone and not rely on the CPU to feed it jobs. The combination of hUMA and hQ means that the GPU has finally broken free of the shackles that had limited its tremendous compute potential.

While OpenCL already offers developers access to the compute power in AMD Radeon GPUs and A-Series APUs, for developers that are used to programming on CPUs, it can be a time consuming task to not only learn OpenCL but build a development workflow around new tools. Therefore AMD has been working hard to make programming the GPU as easy as programming the CPU, through the use of high-level programming languages.

The first high-level language to receive attention from AMD’s engineers is Java. AMD, through Project Sumatra, has been working with the OpenJDK project to make accessing the GPU in one of the most popular, multi-platform high-level programming languages, as easy as accessing the CPU. With millions of Java programmers around the world and OpenJDK being the favored Java SE implementation on a number of Linux distributions, it will bring the considerable compute power in APUs to a huge developer community.

Making it easier for Java programmers to access the GPU wouldn’t be possible without the HSA Intermediary Language (HSAIL), the technology that maps high-level programming commands into low-level instructions that the GPU can operate on. HSAIL abstracts this from the developer, meaning the developer can focus on the functionality of the code and does not have to worry about optimizing for the underlying processor architecture.

HSAIL also offers a target for those developers that want to build tool-chains and is designed to support a multitude of programming languages, including OpenCL, C++, Fortran, OpenMP and of course, Java. HSAIL also has a binary format known as BRIG, which can be embedded in executable files to sit alongside the code that caters for a particular instruction set.

While AMD’s work in Project Sumatra offers high-level programming language access to the GPU, those programmers that want low-level access can do so with HSAIL. As Ben Sander, AMD Fellow and architect for HSA & Main Spec Editor for the HSA Programmer Reference Manual, put it, “Writing in HSAIL is similar to writing in assembly language for a RISC CPU: the language uses a load/store architecture, supports fundamental integer and floating point operations, branches, atomic operations, multi-media operations, and uses a fixed-size pool of registers.”

At the recent AMD Developer Summit, developers had the chance to learn more about Project Sumatra and how it will make the GPU accessible to millions of developers. A panel chaired by Phil Rogers, corporate fellow at AMD and HSA Foundation chairman provided valuable high-level insight to developers, while a number of researchers and engineers gave detailed presentations on the state-of-the-art of HSA.

AMD is not the only company that believes in HSA; ARM, Imagination Technologies, MediaTek, Qualcomm, Samsung, Texas Instruments also founding members of the HSA Foundation. But it isn't just semiconductor companies that see the value in HSA, software vendors such as Canonical, Multicoreware, Oracle and many others are also members of the Foundation.

HSA and its suite of technologies will bring the power of the GPU to high-level programming languages, and with the HSA Foundation being supported by some of the biggest names in the semiconductor industry, it is not surprising that many believe that HSA is the biggest shakeup in processor technology in decades.

Lawrence Latif is a blogger and technical communications representative at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions. Links to third party sites, and references to third party trademarks, are provided for convenience and illustrative purposes only. Unless explicitly stated, AMD is not responsible for the contents of such links, and no third party endorsement of AMD or any of its products is implied.

 AMD FirePro™ graphics engineering teams have spent years optimizing hardware and driver code to improve real-world application performance, visual quality, and advanced feature support. We have been recommending the use of real-world applications benchmarks like SPECapc® for almost half a decade, in order to properly evaluate graphics performance and visual quality. Most professional users only run a few key applications for their day-to-day workflows and it is critical to benchmark their actual applications, right down to the specific versions being used, so that they can purchase the best professional graphics card to meet their specific needs.