This post was authored by Gary Frost, a Software Fellow at AMD







Here at AMD we are committed to provide GPU compute performance from a variety of programming languages. We understand that not every developer will have the flexibility or inclination to port embarrassingly parallel sections of code to OpenCL in order to take advantage of the energy and performance advantages afforded by modern SIMD-style accelerators.

In November of last year I had the opportunity to showcase the state of the OpenJDK Sumatra project at AMD’s APU13 developer summit. “Sumatra” is a joint AMD/Oracle project which allows the Java Virtual Machine’s JIT (Just In Time) compiler infrastructure to generate code suitable for GPU offload. When fully realized this will allow Java developers to see their Java code accelerated by the JVM and dispatched to the GPU automatically at runtime.





At APU2013 Nandini Ramani (Vice President of Java Platform at Oracle Corporation) and Phil Rogers (Corporate Fellow at AMD) made some time in their keynote presentations to call out the work of the Sumatra team and to highlight the hardware and software features that allow Sumatra to bring GPGPU compute to the Java community.





Specifically in Nandini’s keynote I demonstrated our ‘Dickens’ demo. This showed how a simple search algorithm coded using standard Java 8 patterns and idioms could be executed on a HSA enabled platform. The code created a histogram of names present in a subset Charles Dickens’ novels. Thanks to HSA’s shared virtual memory, the Java user interface was able to update in real time as the Java code searched through the text. With the Java 8 Stream APIs the user can switch easily between a sequential and parallel implementation, and on a HSA enabled platform the Sumatra enabled JVM was able to execute parallel fragments directly on the GPU cores.





From a performance point of view, at APU13 we successfully demonstrated the JVM seamlessly migrating this Java workload from CPU multicore APU graphics cores with very little effort from the Java developer.





This demo was well received, but was essentially unrepeatable by the general public as we were showing an early Sumatra ‘drop’ running on a pre-release Java 8 JVM, on a prerelease internal HSA runtime and on prerelease “Kaveri” APU hardware on a set of Windows drivers specially composed for the demonstration. In the words of Phil Rogers “how could this possibly go wrong?”





What a difference six months makes. In January of this year AMD released the new AMD A-Series APU (code named “Kaveri”) allowing all sorts of applications to take advantage of the GPU cores on this processor.





At the end of February the HSA Linux driver team within AMD made available the Linux Kernel patches and drivers to allow the Linux kernel to coordinate the execution of code on the GPU compute units within a HSA enabled platform.





Also in February the HSA runtime team from AMD made available an early access Linux HSA runtime, which allows projects such as Sumatra to dispatch HSA kernels on the HW from user mode.





To align with this the Sumatra developers (both at AMD and over at Oracle) added their first round of HSA support to the Graal infrastructure which Sumatra uses to generate code for GPUs.





At the end of March Oracle released Java 8.





So now the stars have aligned and anyone with a HSA compatible Linux kernel on HSA compatible hardware can recreate the demos we showed at APU2013 from publically available software and hardware.





Now in April, we have showcased all of these components running on Fedora at the Red Hat Summit. Congratulations to all the folk at AMD, the HSA foundation, and our friends at Oracle for getting us to this point.





We have Great Expectations for the future of Sumatra.









Gary Frost is a Software Fellow 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.

*Originally Posted by llatif in AMD Business on Apr 25, 2014 5:54:00 AM