NVIDIA’s CUDA is easily the most popular programming language for general-purpose GPU computing. But one of the more interesting developments in the CUDA-verse doesn’t really involve GPUs at all. In September, HPC compiler vendor PGI (The Portland Group Inc.) announced its intent to build a CUDA compiler for x86 platforms. The technology will be demonstrated for the first time in public at SC10 this week in New Orleans.

To delve a little deeper into the what’s behind the CUDA x86 effort, HPCwire asked PGI senior compiler engineer Michael Wolfe about the rationale for producing such a product and how the technology will work.

HPCwire: Why CUDA for x86? Aren’t there enough parallel programming environments already available for this architecture?

Michael Wolfe: There are certainly many parallel programming approaches today, and no one would have created an analog to CUDA if the x86 were the only target. However, CUDA has been quite successful for programming NVIDIA GPUs. There are now customers who want portability of their CUDA programs beyond NVIDIA and GPUs. The PGI CUDA X86 compilers will provide that portability.

HPCwire: Do you think there is existing demand for such a product, or is this more of a if-we-build-it-they-will-come approach?

Wolfe: There is definitely demand for this. We approached our customers and surveyed the market before proceeding. We didn’t come up with this idea on our own.

HPCwire: What x86 hardware is being used to map the CUDA functionality? Is the intent to support both Intel and AMD platforms going forward?

Wolfe: We think of today’s GPUs as exploiting three levels of parallelism: SIMD parallelism within a “warp” (or thread block) and within a streaming multiprocessor; MIMD parallelism across thread blocks and across multiple streaming multiprocessors; and multithread parallelism, used to tolerate device memory latency. Today’s x86 processors have SIMD parallelism in the SSE (and soon AVX) instructions and MIMD parallelism across the multiple cores. Intel processors even support a limited amount of multithread parallelism. Our compilers will use the SSE, AVX and multicore parallelism.

HPCwire: What’s the point behind compiling to a “Unified Binary?” Using the same code base to target different platforms seems obvious, but at run time, won’t users know what the target is? Are you envisioning a cluster deployment scenario where only some of the nodes are equipped with GPUs, with the rest CPU only?

Wolfe: It’s not likely users will make production runs on clusters where only some of the nodes are GPU-enabled. The PGI Unified Binary allows HPC users who regularly access multiple server platforms to build one version of their application that is optimized for Intel, AMD and GPU-enabled compute nodes. Some sites even use it to ease the transition from one generation of Intel or AMD CPU to the next. The PGI Unified Binary for multiple x86 CPUs has been quite popular with independent software vendors who want to ship optimized applications without having to manage a different binary for each different processor type. We expect the same to be true for CUDA; a vendor or developer can produce a single executable that will execute using a GPU when available, and use the host otherwise.

HPCwire: Beyond that, is their any utility to writing x86-specific CUDA source code that is optimized for the CPU?

Wolfe: As I said before, an API-based programming model like CUDA probably would never have emerged simply to support multicore x86 CPUs. It was designed with the structure required for efficient GPU programming and for programming heterogeneous systems with multiple memories. That said, it can be compiled for efficient execution on x86 using multiple cores and SSE/AVX to effect parallel execution. For that reason, it has value as a uniform parallel programming model across GPUs and multicore x86.

HPCwire: Is there any intelligence in the compiler to map some of the CUDA parallelism to the CPU and some to the GPU, based on available resources?

Wolfe: CUDA is a relatively low-level programming model. The program — meaning the programmer — explicitly allocates memory on the GPU or CPU device, copies data to and from the memory, and launches kernels on the device. It’s beyond the scope of a CUDA compiler to distribute the data across multiple memory spaces, manage the data motion between them, and decide what parts of the kernel domain to allocate to what devices.

HPCwire: You are demonstrating the technology at SC10. What’s the timeframe for the product launch?

Wolfe: The product will launch in three phases. The first phase, due in Q2 2011, will include CUDA functionality on the x86, allowing execution and debugging, but not optimized for high performance. The second phase, planned for Q4 2011, will use the SSE and/or AVX instructions and other performance optimizations. The third phase will include the Unified Binary technology, allowing a single executable to run on the GPU or the x86. The time frame for phase three is sometime in mid-2012.

HPCwire: What will it cost?

Wolfe: The current plan is to add CUDA C for multicore x86 as a new feature in our existing PGI Accelerator product line. Customers who already have PGI Accelerator licenses with active subscriptions will get PGI CUDA C at no extra cost as part of their standard release updates when it rolls out.