NVIDIA is set to release a new CUDA toolkit to developers this Friday with the 4th generation of its popular GPU software suite. The company says CUDA 4.0 is designed to make parallel programming simpler, thus bringing more application developers into the GPGPU fold. Some of the new capabilities also foreshadow Project Denver, the codename for the company's future CPU-GPU architecture for workstations, servers, and supercomputers.

The 4.0 toolkit brings with it three new technologies: GPUDirect 2.0 for peer-to-peer communication among graphics chips on the same compute node; Unified Virtual Addressing (UVA) to provide a single address space that melds CPU and GPU memories; and Thrust, a set of C++ library of data structures and algorithms aimed at parallel programming.

According to Sumit Gupta, senior product manager for NVIDIA Tesla GPU Computing Unit, the enhancements are geared toward raising the abstraction level for the GPGPU programmer, making it easier for less GPU-savvy developers to take advantage of the architecture's high-performance data parallelism. CUDA already has a good deal of traction in the HPC community, and is even becoming well-supported by CAE software vendors like ANSYS, SIMULIA, and ACUSIM.  With 4.0, NVIDIA is looking to cast a wider net and bring more mainstream developers into the GPU computing camp.

"The focus for us now is to get more people to use GPUs," says Gupta. "Clearly, we have a pretty good mindshare in the HPC community at this point. Now it's just going broader and deeper."

For example, GPUDirect 2.0, is the second generation of the technology whose original version allowed third-party PCI devices like network adapters and SSDs to bypass the CPU and tap directly into GPU memory. The 1.0 technology is supported by Mellanox and QLogic, who have incorporated the GPUDirect smarts into their respective InfiniBand adapters.

Likewise, the second version of GPUDirect enables multiple GPUs in the same node or workstation to access each other's memory over the PCI bus, without having to copy data to the system memory. For multi-GPU applications, the new GPUDirect promises both better performance (less copying of data and less CPU overhead) as well as less onerous programming (no routine calls to copy data to back and forth to system memory). According to Gupta, at some future date they'd like to apply this peer-to-peer GPU communication capability out to the cluster interconnect.

Extending the memory abstraction even further is the new Unified Virtual Addressing feature. In this case, CUDA provides a single address space that virtually merges system memory on the CPU side with the memory of one or more connected GPUs.This gives the application a view of all the heterogeneous memories as a single memory space.

Today a developer has to keep track of where data is and explicitly copy data to GPU memory if it’s not there before calling a function that uses the data. With UVA, the function itself can disambiguate where the data is and copy it appropriately. This, in particular, helps libraries become more self-contained and reduces the burden on the application developer.

Similarly for multiple GPUs, functions that use the GPU can now figure out which device the data is on and copy the data between them, instead of the developer “pre-conditioning” or copying the data before calling the function. The general idea here, Gupta says, is speed up the original CPU-to-GPU application port, and let the developers use the tools to work out any needed optimizations.

The UVA feature also has an eye toward the Project Denver architecture, which will integrate ARM CPUs and NVIDIA GPUs on the same chip, presumably making separate physical memory spaces a thing of the past. Thus, all CUDA applications developed with UVA should slide easily onto these heterogeneous platforms. "We always knew the Denver architecture was coming, so we've always planned for it in the CUDA programming models," says Gupta. "Features like Unified Virtual Addressing are meant to extend out to future architectures."

The other big enhancement in CUDA 4.0 is Thrust, a C++ template library that contains algorithms and data structures aimed at parallel programming. Once again, the idea is raise the abstraction level, in this case, for C++ programmers, so that developing parallelized applications is much more straightforward. Although C++ is not widely employed in traditional HPC (outside its use by quants for financial applications), the language is widely adopted across IT, from the consumer side to the enterprise.

To help boost performance, at compile time Thrust will attempt to choose the fastest code path for the hardware it's to be run on. In this case, that means it will divide the work between the GPUs and CPUs to maximize throughput -- yet another nod to the upcoming Denver architecture. NVIDIA claims Thrust routines such as parallel sorting are 5 to 100 times faster than the corresponding implementations of the Standard Template Library (STL) and Threading Building Blocks (TBB).

Besides the big three enhancements, CUDA 4.0 will also sport some new capabilities like being able to share a GPU with multiple CPU threads. So for example, if you have four threads running on a quad-core CPU, all those threads can drive computations on a single GPU. Previously, you would have needed four GPUs to do this or would have been restricted to executing each thread sequentially on the GPU side. Conversely, CUDA 4.0 will also let you drive multiple GPUs using a single CPU thread.

Also included in the new toolkit is an MPI implementation that automatically moves data to and from the GPU memory over InfiniBand when an application does an MPI send or receive, a new NPP image and computer vision library, an auto performance analysis capability for the Visual Profiler tool, a GPU binary disassembler, and some new features in cuda-gdb debugger.

The CUDA 4.0 toolkit will be released free of charge to registered developers on March 4th. By announcing it a few days in advance, NVIDIA is hoping to attract some new blood into the CUDA Registered Developer Program. No date is set for general release of the toolkit, but usually there's just a couple of months lag time between the release candidate and the final version.