At ISC this year, there are plenty of sessions devoted to manycore processors, especially in the role of HPC accelerators. Not surprisingly, a lot of these are centered on the current sweetheart of manycore: GPUs. One of the most well-attended sessions here at ISC’11 was “The GPU Debate” between NVIDIA Fellow David Kirk and LSU professor Thomas Sterling, where the two bantered about the architecture, its evolution as a general-purpose HPC processor, and its roadmap to exascale.

HPCwire caught up with Kirk and asked him about some of the specific challenges of GPU computing today and how he views the role of integrated CPU-GPU architectures as they come into play.

HPCwire: Is there any thought at NVIDIA to proposing CUDA as an open standard for the GPU/manycore computing community?

David Kirk: There are no plans to turn CUDA into an open standard at this point. Right now, the only processors we see being deployed widely in servers are x86 CPUs and NVIDIA GPUs and these are all supported by CUDA toolkits today. NVIDIA offers developers choice – choice to use CUDA C, CUDA C++, CUDA Fortran, OpenCL, or DirectCompute to program CPU-GPU systems. We chair the OpenCL working group, we have collaborated closely with Microsoft on DirectCompute and continue to do so as they evolve these platforms. But CUDA is our platform for innovation. We recently released CUDA 4.0, which is a huge leap forward in programmer productivity with features like unified virtual addressing and the new Thrust C++ template library. We continue to move CUDA forward at a rapid pace.

HPCwire: There has been plenty of talk about the problems involved in hanging a GPU processor off of a PCI bus for use as an external accelerator – I/O overhead and the software messiness of having to do explicit data transfers. What do you think are the biggest limitations of the current GPU processors from a hardware point of view, in regard to high performance computing?

Kirk: The PCIe bottleneck concern is hotly debated and we hear about it a lot. We are aware of very few applications that are bottlenecked by transfer speeds. Incidentally, the PCIe bus is often not the slowest bus in the system. Network and disk interfaces are slower, and in many systems the CPU memory path is slower!

That being said, there are two things that have changed since this concern first surfaced. First, we now have 6 GB of on-board memory and second, our new NVIDIA GPUDirect technology is eliminating the CPU and GPU memory bottlenecks from the path.

These enhancements reduce the PCIe bottleneck. Data can directly stream from storage to the GPU memory via GPUDirect and the larger GPU memory enables more data to reside on the GPU without communicating to the CPU. Our future GPU architectures will continue to reduce dependence on and communication with the CPU, thus eventually very significantly limiting the PCIe bottleneck. By the way, Vincent Natoli summarized it nicely in his recent HPCwire article.

I personally believe though, that the biggest limitation of GPU computing is the misconception that it’s too hard. Put this into whichever bucket you wish — ease of use of the software, the programmability of the hardware, the performance, per watt, per dollar. However you slice it, there have been many reasons cited as to why not to adopt GPU computing.

We’ll be the first to say that parallel computing is challenging. I personally co-teach the parallel computing course, along with Dr. Wen-mei Hwu, at the University of Illinois at Urbana-Champaign, so I know first-hand what it is like to switch the mindset from a purely serial based model to thinking about problems in a multi-threaded parallel environment.

But the rewards are significant. Change two percent of your code and in many cases you can see up to a 10X increase in performance. That’s a pretty big bang for your software development buck. And, we live in a parallel computing world now, so serial programming is no longer a viable option.

HPCwire: Same question for software side. What are the biggest limitations of the current GPU computing software frameworks?

Kirk: One of the most common concerns I hear from the community is the portability aspect of CUDA and the fact that it only runs on NVIDIA GPUs. As I said before, we remain agnostic on language. Fortran, Python, C, C++, Java, OpenCL, DirectCompute – we support all these languages, either internally or through 3rd parties. If you choose to use NVIDIA GPUs, then we will ensure that have you the widest choice of languages.

With regards to the portability of the hardware platform, PGI has just announced the first version of CUDA x86, that enables CUDA code to be compiled down to x86 CPUs. This facilitates easier-than-ever deployment of CUDA-enabled applications across hybrid GPU/CPU systems and is an important milestone in the increased portability of CUDA. There are also several tools created by universities and 3rd-parties to convert CUDA source code to OpenCL source code, which can be compiled for any platform that supports OpenCL. So, portability is no longer a realistic objection but more of an excuse.

Training the millions of software developers who are already in the industry to program in parallel – that is the biggest challenge facing HPC and parallel computing in general. This is where the elegance of the CUDA parallel programming model really helps and the reason why it has caught on so quickly and so widely. CUDA C/C++ is an incredibly powerful language of authorship, and we have found that it is quite easy to learn.

HPCwire: Do you think the appearance of heterogeneous CPU-GPU processors portends the demise of discrete GPUs – for GPU computing or otherwise? Do you think it will spell the end of “pure” CPUs?

Kirk: A lot of folks believe that integrating CPUs and GPUs together is a panacea. As you well know, this is easy for NVIDIA to do. We have the highest volume integrated CPU-GPU SoC shipping today: our Tegra mobile SoC. But if you scale this to HPC, the challenge is that you have to compromise either on the performance of the CPU or that of the GPU. The silicon area is fixed, so you have to put a medium performance CPU with a medium performance GPU. Not exactly HPC! We find that none of our customers ever ask us for less performance.

For the foreseeable future, there will be a market for a discrete CPU and a discrete GPU – the performance users, whether in HPC or in gaming or CAD workstations, need the best of both. But a swing we already see happening is that applications are leaning more on the GPU for performance than on the CPU — both gaming and HPC. This is because performance scaling on CPUs seems to have reached an end. Laptops are not going beyond dual-core x86 CPUs. Even on HPC, application performance is not scaling beyond 4 cores. They end up choking on memory bandwidth.

Clearly, the personal computer experience is going to be dominated by SoCs with integrated ARM cores and GPUs. This is happening today and will be solidified by support for ARM in Windows Next. But as I said above, we expect that there will be a CPU + GPU market for a very long time to come.

HPCwire: How will users be able to port codes developed today with CUDA, OpenCL and accelerator-directives to the future shared-memory architectures of CPU-GPU integrated processors envisioned by “Project Denver” AMD Fusion, etc.?

Kirk: The beauty about the CUDA programming model is that it was designed for CPU-GPU based heterogeneous architectures. Whether the CPU and GPU are integrated does not change the programming model. Integration is simply a cost consideration. After all, we have been working on Tegra — ARM + GPU SoCs — for just as long as we have been working on CUDA. Other driver-level APIs like OpenCL treat the GPU as a device that is separate from the CPU (host) and this means that OpenCL as defined today has to be extended to support an integrated CPU-GPU device. This means that applications written with the CUDA toolkits will just work on our integrated CPU-GPU devices.