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.

 At last month's SC'13 conference in Denver, a team from Bentley University and Northeastern University took the top spot in the Student Cluster Competition under the new Commodity Cluster track with a cluster powered by AMD's A-Series Accelerated Processing Units (APU). The team beat others from Slippery Rock University, Skyline High School and Arizona State  University .

 The team was comprised of five students, with Conner Charlebois, Nicholas Hentschel and Dmitry Veber from Bentley alongside Neel Shah and Tushar Swamyfrom Northeastern. The students were mentored by Bentley Professors Irv Englander and David Yates along with PhD student Yash Ukidave and Professor David Kaeli from Northeastern.

 The Student Cluster Competition comprises of two tracks, with the Standard Track having no budgetary constraints and a Commodity Track placing tough power and monetary limits on competitors. Under the Commodity track, Bentley and Northeastern had to build a HPC cluster within a 15 amps power budget, with components that cost no more than US$2,500.

 With such tight constraints, the students from Bentley and Northeastern performed experiments to determine the optimal configuration of compute, power utilisation and cost effectiveness and decided that AMD's revolutionary APUs offered them the best chance of winning the prestigious Competition.

 As the name suggests, the Commodity Track makes takes off-the-shelf hardware to create a HPC cluster. That means anyone can buy the hardware that powered Bentley and Northeastern to glory.

 The cluster's seven compute nodes were powered by AMD A-Series A10 5800K APU with the head node using an AMD A-Series A10 6800K APU, strapped into ASRock FM2A75M-DGS R2.0 motherboards. Each compute node had 8GB DDR3 clocked at 2,133MHz while the head node had 16GB DDR3 clocked at 1,866MHz. Including the supporting equipment, such as power supply units, hard drives, network switches and cables, the price for an eight node HPC cluster came out to less than US$2,500.

 The Student Cluster Competition ran for 48 hours, with four industrial-strength benchmarks being used to evaluate the clusters. Prior to the competition the team knew only three of the four applications in-advance, with the final application being disclosed on event day, making the challenge of optimising their cluster even harder.

 The three applications that were known prior to the competition were: weather research and forecasting, nanoelectronics modelling tools, and GraphLab. As the teams set up the eight-node APU HPC cluster, they were told the final workload was “Flying Snakes,” a computational fluid dynamics simulation. All of these applications provide a good sample of the workloads that are run on multi-million dollar supercomputer clusters.

 Not only did the Bentley and Northeastern cluster win the Commodity Track, but its score over the four workloads was higher than three teams in the Standard Track. This was an outstanding accomplishment as teams on the Standard Track not only had access to 30 amps of power but also unlimited budget.

 Yates said, “The Bentley University and Northeastern University students picked the AMD A10 family of APUs for its performance per-dollar. AMD’s system on-a-chip design also gave the team a symmetrical cluster design within this chip family, with x86 double precision floating point performance being most important over the course of the 48-hour  competition .”

 The floating point performance Yates was referring to comes from a combination of the AMD A10's multi-core x86 architecture and the AMD Radeon GPU that supports the OpenCL™ programming language.

 Kaeli and his students have long seen the compute potential in APUs. He said, “We have a team here at Northeastern that has been working with APUs and OpenCL for a number of years, and together with the Bentley members of the team, we were able to be very competitive and strategic during the  competition  .”

 The exploits of Bentley and Northeastern highlight the fundamental compute power that each AMD A-Series APU has by combining a powerful multi-core x86 CPU with a programmable AMD Radeon GPU that supports the industry standard OpenCL programming language. The ability for the team to build an eight node cluster, given the power and budget limitations set by the Student Cluster Competition, shows the incredible performance per-watt per-dollar that an AMD A-Series APU is capable of delivering to desktops, laptops, tablets and even supercomputers.

 By making the smart choice, Bentley and Northeastern not only won the Student Cluster Competition in style, but showed that AMD's A-Series APUs can mix it in the competitive world of HPC.

Team members

Conner Charlebois, Computer Information Systems undergraduate (class of 2014), Bentley University

Nicholas Hentschel, Computer Information Systems undergraduate (class of 2014), Bentley University

Neel Shah - ECE undergraduate (class of 2015), Northeastern University

Tushar Swamy - ECE undergraduate (class of 2015), Northeastern University

Dmitry Veber, Actuarial Science undergraduate (class of 2014), Bentley University

Team mentors

Irv Englander, Professor Emeritus, Computer Information Systems, Bentley University

David Kaeli - ECE Professor, Northeastern University

Yash Ukidave - ECE PhD student, Northeastern University

David Yates, Associate Professor, Computer Information Systems, Bentley University

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.