As we get closer to the launch of NVIDIA’s K20 GPU later this year, the company is continuing to sharpen its storyline around the new product. The K20 is the Kepler-generation processor aimed squarely at the supercomputing space and, unlike the K10, incorporates all the bells and whistles for that high-end user base. One of the features the company has talked about at some length is Hyper-Q , and in a recent blog post by Nvidian Peter Messmer, he makes a more specific pitch about how the technology is going to boost the performance and programmability these new devices.

In a nutshell, Hyper-Q is designed to support MPI applications a lot more effectively than in NVIDIA’s Fermi-generation GPUs. In the current architecture, there is only a single work queue to field MPI processes from the host processor. Since the host driver is invariably a multicore x86 chip, there are potentially as many MPI processes in flight as there are cores on the CPU. But with a single work queue on the GPU side, all of the MPI work has to processed serially.

And this would all be fine if each MPI-related computation filled up the GPU, but that’s rarely the case. The result is that much of GPU is idle while it waits for the next MPI process in the queue to kick off. And the CPU is also stuck waiting for the GPU work queue to clear. To get around this, programmers are forced to rip apart their codes so that the GPU has more work to do.

Hyper-Q fixes this by creating 32 work queues in the hardware. So up to 32 MPI tasks can be running on the GPU simultaneously, or until the processor fills up. The bottom line is that more work can be done by the GPU in a given amount of time. The CPU is happier too, since the work being sent to the GPU is being consumed at lot faster.

Messmer says the best part of this is that developers don’t need to modify their codes to rebalance the work for the GPU. They can just run the MPI application as is — running it through the latest CUDA SDK — and the K20 hardware will suck up to 32 MPI processes into the GPU and do all the work balancing automatically. To the application, that makes it feel more like one multicore CPU talking to another.

The example Messmer illustrates in his blog post is CP2K, an open-source application that does atomic and molecular simulations. Running it on a Fermi part, produced little speedup compared to a CPU-only rung, but using a K20, they were able to get a 2.5x performance boost.

Although the K20 won’t be available until the fourth quarter, Messmer says you get ahead of the game and start porting your MPI code to GPUs today with the new OpenACC compiler technology. OpenACC is a high-level framework that uses directives inserted in regular source code to tell the compiler which application pieces are going to the GPU. For MPI processes, directives are inserted into corresponding source, and the compiler generates the code to funnel the computation to the GPU. With Hyper-Q in effect, that work will now be executed in as parallel a manner as possible.