Login name……let me think, first initial last name? Oh no, that’s right, I think it’s my email address, let’s try that.

Password, that’s my old standby ‘judy123’. Drats, didn’t work. Oh wait, I think this website made me put in a capital letter, ok let’s try ‘Judy123’. Double drat. Ok, that’s right, I think I had to put in a special character too, let’s try ‘Judy123&’. Triple drat!

Ok, let me find my post it note with all my login names and passwords - oh, there we go. That was easy…
Actually, the better question is not “has this happened to you,” but “how many times a day does this happen to you?”
As we put an increasing amount of personal data online, privacy and security are necessarily on everyone’s mind. Yet with no standard rules regarding login names and passwords, we are confronted with a dizzying array of authentication schemes and login routines that we need to recall. That leads to bad habits (securing your banking info, Netflix account and Facebook with your pet’s name) and the repeated frustration I described above.
Why don’t our own computers recognize us?
Some steps have been taken in that direction. Some business-oriented laptops have fingerprint readers-- a good idea, but can be costly.
It would make more sense if the rest of us could take advantage of the hardware we already have, but gain the benefits and convenience of being recognized by our computers.

Not only did the team win, but it beat a number of teams that had double the power available to them and unlimited budget. To see what they did, read AMD A-Series APUs power Bentley and Northeastern university students' Cluster Competition submission to glory at Super Computing 2013.

The Bentley and Northeastern students were able to achieve this outstanding feat through a combination of hard work and picking the right tools for the job. The team was the only one to use APUs, while other competitors made use of traditional CPUs, and in the case of two teams, pairing them with consumer GPUs.

Since 2011, AMD's A-Series APUs have provided compelling performance and value for money by combining multiple x86 CPU cores and a Radeon GPU on a single chip. APUs deliver stunning visuals and immense, power-efficient compute capability while supporting the OpenCL™ programming language - a great combination for desktops, laptops and tablets. Students from Bentley and Northeastern have now shown that APUs can also serve as the basis for cost-effective, power efficient high performance computing cluster.

But what makes an APU good for HPC applications? AMD's Shankar Viswanathan, an engineer who has worked on several generations of AMD's APU architecture and provided advice to the Bentley and Northeastern team, explained some details around the hardware and software that makes an AMD APU a compute powerhouse.

• The APU's memory architecture - “The APU allows very low latency transfer of data processing from CPU to GPU and vice versa. Due to the APU's implementation of an on-die memory controller, the latency is lower than if it were on a discrete GPU that used the PCI-Express bus.”
• AMD Turbo Core - This allows power to be shifted between CPU and GPU depending on load. Viswanathan explains, “This technology allowed the Bentley and Northeastern team to use the same hardware for both the CPU intensive application as well as the GPU focused one. In one of the applications they even did some initial serial processing on the CPU and then enabled the GPU to do all the data parallel operations. Turbo core allowed them to really boost the speed when only one of the CPU or GPU was active.”

Going into detail on AMD Turbo Core, Viswanathan said, “The technology allows CPU clock speeds to be increased dynamically when encountering execution scenarios that are primarily suited to the CPU. Turbo Core can also boost GPU frequency when executing GPU intensive tasks. This versatility is crucial in a dollar and power constrained environment such as the Student Cluster Competition, but the benefit can extend to some HPC workloads in industry and academia".

And with AMD's future APUs sporting Heterogeneous System Architecture (HSA) features, Viswanathan said that the APU will offer great performance potential for the HPC community. “One of the main advantages of using AMD APUs for HPC workloads with HSA technology is that it allows both the CPU cores and the GPU to collaboratively process huge data sets, thus accelerating the program execution.”.

Having top-notch hardware is only part of the formula when squeezing optimal performance out of a HPC cluster, with software also playing a crucial role. Viswanathan pointed out three tools that can help developers extract the most from an AMD APU.

• AMD Core Math Library - a free optimised and threaded math library that provides functions such as BLAS, LAPACK, FFTs and random number generators;
• AMD APP SDK - helps developers to leverage programming languages such as OpenCL, Bolt, C++ AMP, or Aparapi to access the compute power within the GPU;
• AMD OpenCL driver - optimised for AMD APUs.

AMD's A-Series APUs have long been compelling processors for desktops, laptops and tablets, but the combination of a powerful multi-core x86 CPU and a Radeon GPU on a single die, coupled with tremendous software support, makes it a great choice for HPC workloads. With HSA, APUs will deliver even more compelling power efficient performance at an affordable price.

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.

 Before we explore the drastic improvements presented with XDMA, however, we should first start by exploring the old way of performing multi-GPU communication.

 THE OLD WAY OF DOING MULTI-GPU

 Prior to the advent of XDMA, a “bridge” or “connector” of some fashion was required. This bridge was installed on the exterior of a graphics card, fitting onto small golden fingers protruding from the circuit board of the graphics card. You can see the connector to the right, where it has been installed on two AMD Radeon™ HD 7970 GHz Edition GPUs .

 An external bridge was considered a modern solution that gave two (or more) GPUs the ability to communicate on a very important task: copying data between the GPUs to show you a rendered frame of your favorite game.

 While the external bridge has been an effective multi-GPU solution for many years in the graphics industry, we are coming on an era when that is no longer the case. To wit, the bandwidths provided by today’s bridge solution are insufficient to fully accommodate the new generation of high-resolution 4K displays. As the AMD Radeon R9 290 and R9 290X are designed with this resolution in mind, it was time to bring in a fresh approach to multi-GPU systems.

 MODERN MULTI-GPU WITH XDMA

 At a principle level, XDMA dispenses with the external bridge by opening a direct channel of communication between the multiple GPUs in a system. This channel operates over the very same PCI Express® bus in which your AMD Radeon graphics cards are currently installed. The exclusive function of that bus is to shuttle graphics data between GPUs and your processor, so it’s already well suited to the new task of collecting and showing the data each GPU is working on when playing games.

 It just so happens that the PCI Express bus also provides a tremendous amount of bandwidth—far more than can be allocated to today’s external bridges! As noted by Anandtech in their comprehensive analysis of XDMA, the bandwidth of an external bridge is just 900MB/s, whereas PCI Express® can provide up to 32GB/s with a PCIe 3.0 x16 slot (about 35x more bandwidth).

 In dynamically taking a portion of that superhighway to negotiate rendering with multiple GPUs, AMD CrossFire can efficiently negotiate UltraHD scenarios. This is one of the many reasons why we say that the AMD Radeon R9 290 and R9 290X are uniquely suited, at a hardware level, for gaming at 3840x2160.

 Diving more deeply into the technology, XDMA specifically and directly connects the “display controllers” on the respective GPUs in an AMD CrossFire configuration. These display controllers are responsible for taking a rendered scene in a game from the GPU pipeline and formatting it to send over the display cable to a monitor. XDMA provides an easier and more extensible method of transferring the frame from the GPU it was rendered on, to the GPU driving the display cable, using the high bandwidth of PCIe, while avoiding extra connectors and cables.

 FACTS ABOUT XDMA

 Rather than dig through more technical jargon, we wanted to jump to some essential facts that we wanted you to know about this great technology:

• XDMA is a unique solution in the graphics industry; no similar technologies presently exist for consumer GPUs.
• In case you didn’t catch it, XDMA eliminates the need to install any bridge. Install matching GPUs and you’re set!
• XDMA is designed for optimal performance with systems running PCI Express 2.0 x16 (16GB/s), PCI Express 3.0 x8 (16GB/s), or PCI Express 3.0 x16 (32GB/s).
• Bandwidth of the data channel opened by XDMA is fully dynamic, intelligently scaling with the demands of the game being played, as well as adapting to advanced user settings such as vertical synchronization (vsync).
• Designed for UltraHD via DisplayPort™, which permits for 2160p60 gaming on the AMD Radeon R9 290 Series.
• XDMA fully supports the “frame pacing” algorithms implemented into the AMD Catalyst™ driver suite.
• Products without XDMA are scheduled to receive a new AMD Catalyst driver in January that will resolve uneven frame pacing as a symptom of the more limited bandwidth provided by an external bridge.

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.