Blogs

State of GPU Virtualization for CUDA Applications 2014

Introduction

Wide spread corporate adoption of virtualization technologies have led some users to rely on Virtual Machines (VMs). When these users or IT administrators wish to start using CUDA, often the first thought is to spin up a new VM. Success is not guaranteed as not all virtualization technologies support CUDA. A survey of GPU virtualization technologies for running CUDA applications is presented. To support CUDA, a VM must be able to present a supported CUDA device to the VM’s operating system and install the NVIDIA graphics driver.

GPU Virtualization Terms 

  • Device Pass-Through: This is the simplest virtualization model where the entire GPU is presented to the VM as if directly connected. The virtual GPU is usable by only one VM. The CPU equivalent is assigning a single core for exclusive use by a VM. VMware calls this mode virtual Direct Graphics Accelerator (vDGA).
  • Partitioning: A GPU is split into virtual GPUs that are used independently by a VM. 
  • Timesharing: Timesharing involves sharing the GPU or portion of between multiple VMs. Also known as oversubscription or multiplexing, the technology for timesharing CPUs is mature while GPU timesharing is being introduced. 
  • Live Migration: The ability to move a running VM from one VM host to another without downtime.

Virtualization Support for CUDA 

CUDA support from five virtualization technology vendors accounting for most of the virtualization market was examined. The five major vendors are VMWare, Microsoft, Oracle, Citrix and Red Hat. A summary is shown in the table below.

New whitepaper: OpenCL on FPGAs for GPU Programmers

In 2012 Altera announced their commitment to developing a SDK that would enable developers to program Altera field-programmable gate arrays (FPGAs) with Open Computing Language (OpenCL). This whitepaper introduces developers who have previous experience with general-purpose computing on graphics processing units (GPUs) to parallel programming targeting Altera FPGAs via the OpenCL framework.

This paper provides a brief overview of OpenCL, highlights some of the underlying technology and benefits behind Altera FPGAs, then focuses on how OpenCL kernels are executed on Altera FPGAs compared to on GPUs. This paper also presents the key differences in optimization techniques for targeting FPGAs.

Click here to download the whitepaper.

Altera Whitepaper

Webinar: An Introduction to CUDA Programming

NVIDIA GTC Express webinar recording from May 28, 2014.

Join Chris Mason, Product Manager, Acceleware, for an informative introduction to CUDA programming. The webinar will begin with a brief overview of CUDA and data-parallelism before focusing on the GPU programming model. Chris will explore the fundamentals of GPU kernels, host and device responsibilities, CUDA syntax and thread hierarchy. A programming demonstration of a simple CUDA kernel will be provided.

GTC 2014 Tutorial Recordings are Online

Great news! NVIDIA has posted the recordings of our CUDA programming and optimization tutorials presented at GTC 2014. As a refresher, here are the topics of the tutorials we presented this year:

Part 1: An Introduction to CUDA Programming (Session S4699)
Taught by Chris Mason
Join us for an informative introduction to CUDA programming. The tutorial will begin with a brief overview of CUDA and data-parallelism before focusing on the GPU programming model. We will explore the fundamentals of GPU kernels, host and device responsibilities, CUDA syntax and thread hierarchy. A programming demonstration of a simple CUDA kernel will be provided.

Part 2: GPU Architecture & the CUDA Memory Model (Session S4700)
Taught by Chris Mason
Explore the memory model of the GPU! The session will begin with an essential overview of the GPU architecture and thread cooperation before focusing on the different memory types available on the GPU. We will define shared, constant and global memory and discuss the best locations to store your application data for optimized performance. Features available in the Kepler architecture such as the shuffle instruction, shared memory configurations and Read-Only Data Cache are introduced and optimization techniques discussed. A programming demonstration of shared and constant memory will be delivered.

NVIDIA CUDA 6.0 Unified Memory Performance

One of the new features introduced by NVIDIA in CUDA 6.0 is Unified Memory, which simplifies GPU code, while also maximizing data access speed by transparently managing memory between the CPU and GPU. Based on the examples provided by NVIDIA in the CUDA C Programming Guide, it’s easy to see how Unified Memory simplifies code, however the actual performance is a bit of a mystery. Time to do some investigation!

We begin the performance test by using the sample code provided in NVIDIA’s CUDA C Programming Guide (Section J.1.1)

 

__global__ void AplusB( int *ret, int a, int b) {
   ret[threadIdx.x] = a + b + threadIdx.x;
}
   
int main() {
   int *ret;
   cudaMalloc(&ret, 1000 * sizeof(int));
   
   AplusB<<< 1, 1000 >>>(ret, 10, 100);
   
   int *host_ret = (int *)malloc(1000 * sizeof(int));
   cudaMemcpy(host_ret, ret, 1000 * sizeof(int), cudaMemcpyDefault);
   
   for(int i=0; i<1000; i++)
      printf("%d: A+B = %d\n", i, host_ret[i]);
   
   free(host_ret);
   cudaFree(ret);
   return 0;
}

Listing 1: Original code with explicit memory transfers

 

__global__ void AplusB( int *ret, int a, int b) {
   ret[threadIdx.x] = a + b + threadIdx.x;
}
   
int main() {
   int *ret;
   cudaMallocManaged(&ret, 1000 * sizeof(int));
   
   AplusB<<< 1, 1000 >>>(ret, 10, 100);
   cudaDeviceSynchronize();
   
   for(int i=0; i<1000; i++)
      printf("%d: A+B = %d\n", i, ret[i]);
   cudaFree(ret);
   return 0;
}

Listing 2: Unified Memory version

AMD FirePro W9100 and OpenCL Updates

AMD FirePro W9100

Last week AMD announced the FirePro W9100. This new professional workstation GPU compares favorably to NVIDIA's Tesla K40:

  AMD FirePro W9100 NVIDIA Tesla K40
(745MHz default clock)
NVIDIA Tesla K40
(845MHz clock with GPUBoost)
Memory (GB) 16 12 12
Peak Single Precision
Throughput (TFLOPS)
5.24 4.29 5.04
Peak Double Precision
Throughput (TFLOPS)
2.62 1.43 1.68

Webinar: Accelerating FWI via OpenCL on AMD GPUs

Join Chris Mason, Acceleware Product Manager, as he presents a case study of accelerating a seismic algorithm on a cluster of AMD GPU compute nodes, for geophysical software provider and processor GeoTomo. The presentation will begin with an outline of the full waveform inversion (FWI) algorithm, followed by an introduction to OpenCL. The OpenCL programming model and memory spaces will be introduced. After a short programming example, Chris takes you step-by-step through the project phases of profiling, feasibility analysis and implementation. Chris shares the strategy for formulating the problem to take advantage of the massively parallel GPU architecture. Key optimizations techniques are discussed including coalescing and an iterative approach to handle the slices. Performance results for the GPU are compared to the CPU run times.

 

GPU Boost on NVIDIA’s Tesla K40 GPUs

What is GPU Boost?

GPU Boost is a new user controllable feature to change the processor clock speed on the Tesla K40 GPU. NVIDIA is currently supporting 4 selectable Stream Processor clock speeds and two selectable Memory Clock Speeds on the K40.  The base clock for the Stream Processors is 745MHz and the three selectable options are 666 MHz, 810 MHz and 875MHz (finally, a manufacturer not afraid of superstition!). The base Memory Clock frequencies are 3004MHz (default) and 324MHz (idle). Only the effects of tuning the Stream Processor clock are discussed as there is no application performance increase that results from adjusting the Memory Clock. This blog shows the impact of GPU Boost on a seismic imaging application (Reverse Time Migration) and an electromagnetic solver (Finite-difference time-domain).

GPU Boost is useful as not all applications have the same power profile. The K40 has a maximum 235W power capacity. For example, an application that runs at an average power consumption of 180W at the base frequency will have a 55W power headroom. By increasing the clock frequency, the application theoretically can take advantage of the full 235W capacity.

Enabling GPU Boost

GPU Boost is controlled using NVIDIA’s System Management Interface utility (nvidia-smi) with the following commands:

Command Explanation
nvidia-smi –q –d SUPPORTED_CLOCKS Show Supported Clock Frequencies
nvidia-smi –ac <MEM clock, Graphics clock> Set the Memory and Graphics Clock Frequency
nvidia-smi –q –d CLOCK Shows current mode
nvidia-smi –rac Resets all clocks
nvidia-smi –acp 0 Allows non-root to change clocks

Maximizing Shared Memory Bandwidth on NVIDIA Kepler GPUs

Shared Memory Configurations

On NVIDIA Kepler (Compute 3.x) GPUs, shared memory has 32 banks, with each bank having a bandwidth of 64-bits per clock cycle. On Fermi GPUs (Compute 2.x) shared memory also has 32 banks, but the bandwidth per bank is only 32-bits per clock cycle.

In Fermi GPUs, successive 32-bit words are assigned to successive banks. Kepler GPUs are configurable where either successive 32-bit words OR 64-bit words are assigned to successive banks. You can specify your desired configuration by calling cudaDeviceSharedMemConfig() from the host prior to launching your kernel, and specifying one of cudaSharedMemBankSizeDefault, cudaSharedMemBankSizeFourByte, or cudaSharedMemBankSizeEightByte.

In the eight byte configuration, bank conflicts occur when two or more threads in a warp request different 64-bit words from the same bank. In the four byte configuration, bank conflicts occur if two or more threads in a warp access 32-bit words from the same bank where those words span multiple 64-word aligned segments (Figure 1).

Figure 1 - Bank Conflicts in the Four Byte Configuration

Performance Implications

For kernels operating on double precision values, the eight byte configuration on Kepler allows loads/stores to consecutive doubles without bank conflicts. This is an improvement over Fermi GPUs, where accessing double precision values always incurred bank conflicts. If your kernels are operating on single precision values, you are only utilizing half the available shared memory bandwidth. Modifying your kernels to operate on 64-bit values in shared memory (perhaps using float2) may improve performance if shared memory throughput is a performance bottleneck for your kernel.

Webinar: An Introduction to OpenCL for Altera FPGAs

Join Chris Mason as he presents an informative 25 minute introduction on how to program Altera FPGAs with OpenCL. The webinar begins with an overview of the OpenCL programming model and data parallelism. Chris then discusses simple OpenCL syntax, kernels and memory spaces. Finally Chris examines how OpenCL is mapped to the Altera FPGA architecture. He outlines how to compile an OpenCL kernel to Altera FPGAs and summarizes OpenCL optimizations techniques.

Click here to find out more about OpenCL for Altera FPGA's.

Pages

Subscribe to RSS - blogs