AMD's position in the graphics market continues to be a tricky one. Although the company has important design wins in the console space—both the PlayStation 4 and Xbox One are built around AMD CPUs with integrated AMD GPUs—its position in the PC space is a little more precarious. Nvidia currently has the outright performance lead, and perhaps more problematically, many games are to a greater or lesser extent optimized for Nvidia GPUs. One of the chief culprits here is Nvidia's GameWorks software, a proprietary library of useful tools for game development—things like realistic hair and shadows, and physics processing for destructible environments—that is optimized for Nvidia's cards. When GameWorks games are played on AMD systems, they can often do so with reduced performance or graphical quality.
To combat this, AMD is today announcing GPUOpen, a comparable set of tools to GameWorks. As the name would suggest, however, there's a key difference between GPUOpen and GameWorks: GPUOpen will, when it is published in January, be open source. AMD will use the permissive MIT license, allowing GPUOpen code to be used without any practical restriction in both open and closed source applications, and will publish all code on GitHub.
Making the libraries open source should make AMD's library much more appealing than it currently is. AMD already has offerings in this space; in particular, its TressFX library handles fur and hair generation in a manner comparable to Nvidia's HairWorks. Developers can, if they take the time and effort, even include both; the PC release of Grand Theft Auto V has both TressFX and HairWorks support. But this is extra work, and many developers won't bother. This tends to leave one or other GPU vendor at a disadvantage.
HairWorks and TressFX are both optimized for the GPUs of their respective developers, and they're not currently open source, precluding any optimization effort for the other GPU maker. We've heard that the GameWorks libraries that developers ship with their games aren't even necessarily the ones that get used on end-user systems: the Nvidia drivers replace the library with their own up-to-date routines. This makes the game developer's job even harder, as the code that they're debugging and optimizing will run differently on end-user systems when driver updates are made.
With an open source TressFX included in GPUOpen, along with an open source ShadowFX for shadow processing, GeometryFX for physics, and AOFX for ambient occlusion, the door is open to creating one set of libraries that handle AMD, Nvidia, and even Intel GPUs all optimally. This would make GPUOpen attractive to developers—no need to integrate multiple libraries, but equally, no risk of leaving any of the three major GPU vendors at a serious performance disadvantage—and hence could make GameWorks less appealing. The availability of source will also make it easier for developers to figure out what it's doing and diagnose and debug any problems they may have.
GPUOpen contains much more than just these libraries. It'll also include a set of SDKs such as AMD's FireRender rendering engine, its GPU-accelerated ray tracing SDK, and its RapidFire cloud SDK. It'll also include AMD's CodeXL debuggers and performance profiler. Together, AMD is offering a substantial library of graphical resources, all open source and, in principle, GPU vendor-neutral.
The All Open stack
This embrace of open source is extending to more than just the libraries and tools used by game developers. AMD currently has two Linux driver stacks. There's an all-open Radeon driver and an all-closed Catalyst driver, with the latter tending to be faster and newer. This is being changed. There will be a common open source base graphics driver for AMD's GPUs. On this open source base will be two parallel stacks, each containing modules for OpenGL graphics, motion video codecs, and OpenCL GPU computation.
.
The "All Open" stack will contain open source modules for all of these. The "Professional/Gamer" stack will include the open source motion-video module and a closed source OpenGL module. Its final module, OpenCL, will start closed source, but not permanently: this module will support both OpenCL and Vulkan (the high-performance/low-level, vendor-neutral graphics API that somewhat succeeds OpenGL), and it will "evolve" into open source. When this happens, while the high performance OpenGL module will remain closed source, the modern OpenCL/Vulkan module will be open.
As this evolution happens, it means that Linux will gain access to a full open source, high-performance driver stack, with the only constraint being that developers must use Vulkan instead of the older OpenGL.
The final one of AMD's open source contributions is its "Boltzmann Initiative." AMD's HSA (heterogeneous system architecture) is designed to allow developers to divide workloads between the CPU and GPU in an efficient way and is primarily aimed at typical desktop tasks such as gaming. The Boltzmann Initiative extends the HSA concept to high-performance workloads by adding cluster support, distributing workloads not just between the CPU and GPU within a system but between CPUs and GPUs in multiple systems connected using InfiniBand, and a headless Linux driver for using GPUs without actually driving any displays.
Nvidia's CUDA is already widely used in scientific and industrial GPU compute cluster workloads. To address this, AMD is developing HIP, the Heterogeneous-compute Interface for Portability as part of the Boltzmann Initiative. This is a set of C++ libraries for performing parallel computation, along with a tool for converting GPU computational code from the proprietary CUDA to standard C++ using the HIP library. This HIP C++ can then be compiled with AMD's Heterogeneous Compute Compiler (HCC) for AMD GPUs, Nvidia's NVCC for Nvidia GPUs, or a regular C++ compiler for the CPU. The HCC C++ compiler is built on the open source Clang/LLVM compiler framework.
With HIP and the Boltzmann Initiative's evolved version of HSA, AMD has a chance of opening up the high performance computation (HPC) market in spite of the current CUDA and Nvidia domination. An early access plan will open in the first quarter of 2016, and key parts, including the HCC compiler, will be open source.
Are these things going to put an end to Nvidia's dominance in these fields? Certainly not overnight. The use of GameWorks, for example, is a complex thing, with stories of developers being forced to add support by publishers. There's also some amount of cross-promotion of games optimized for one GPU vendor or the other creating additional incentives. Nonetheless, this set of open source tools should make AMD a lot more competitive in these fields by reducing vendor lock-in.
reader comments
105