Computer Architecture Lecture 9: GPUs and GPGPU Programming

Computer Architecture Lecture 9: GPUs and GPGPU Programming
Prof. Onur Mutlu ETH Zürich Fall 2017 19 October 2017

Agenda for Today GPUs Introduction to GPU Programming
Digitaltechnik (Spring 2017) YouTube videos Lecture 21: GPUs

GPUs (Graphics Processing Units)

GPUs are SIMD Engines Underneath
The instruction pipeline operates like a SIMD pipeline (e.g., an array processor) However, the programming is done using threads, NOT SIMD instructions To understand this, let’s go back to our parallelizable code example But, before that, let’s distinguish between Programming Model (Software) vs. Execution Model (Hardware)

Programming Model vs. Hardware Execution Model
Programming Model refers to how the programmer expresses the code E.g., Sequential (von Neumann), Data Parallel (SIMD), Dataflow, Multi-threaded (MIMD, SPMD), … Execution Model refers to how the hardware executes the code underneath E.g., Out-of-order execution, Vector processor, Array processor, Dataflow processor, Multiprocessor, Multithreaded processor, … Execution Model can be very different from the Programming Model E.g., von Neumann model implemented by an OoO processor E.g., SPMD model implemented by a SIMD processor (a GPU)

How Can You Exploit Parallelism Here?
for (i=0; i < N; i++) C[i] = A[i] + B[i]; Let’s examine three programming options to exploit instruction-level parallelism present in this sequential code: 1. Sequential (SISD) 2. Data-Parallel (SIMD) 3. Multithreaded (MIMD/SPMD) load add store Iter. 1 Iter. 2 Scalar Sequential Code

Prog. Model 1: Sequential (SISD)
for (i=0; i < N; i++) C[i] = A[i] + B[i]; Can be executed on a: Pipelined processor Out-of-order execution processor Independent instructions executed when ready Different iterations are present in the instruction window and can execute in parallel in multiple functional units In other words, the loop is dynamically unrolled by the hardware Superscalar or VLIW processor Can fetch and execute multiple instructions per cycle load add store Iter. 1 Iter. 2 Scalar Sequential Code

Prog. Model 2: Data Parallel (SIMD)
for (i=0; i < N; i++) C[i] = A[i] + B[i]; Vectorized Code load add store Iter. 1 Iter. 2 Scalar Sequential Code Vector Instruction load add store load add store VLD A  V1 VLD B  V2 VADD V1 + V2  V3 VST V3  C Iter. 1 Iter. 2 Realization: Each iteration is independent Idea: Programmer or compiler generates a SIMD instruction to execute the same instruction from all iterations across different data Best executed by a SIMD processor (vector, array)

Prog. Model 3: Multithreaded
for (i=0; i < N; i++) C[i] = A[i] + B[i]; load add store Iter. 1 Iter. 2 Scalar Sequential Code load add store load add store Iter. 1 Iter. 2 Realization: Each iteration is independent Idea: Programmer or compiler generates a thread to execute each iteration. Each thread does the same thing (but on different data) Can be executed on a MIMD machine

Prog. Model 3: Multithreaded
for (i=0; i < N; i++) C[i] = A[i] + B[i]; load add store load add store Iter. 1 Iter. 2 Realization: Each iteration is independent Idea: Programmer or compiler generates a thread to execute each iteration. Each thread does the same thing (but on different data) Can be executed on a MIMD machine This particular model is also called: SPMD: Single Program Multiple Data Can be executed on a SIMT machine Single Instruction Multiple Thread Can be executed on a SIMD machine

A GPU is a SIMD (SIMT) Machine
Except it is not programmed using SIMD instructions It is programmed using threads (SPMD programming model) Each thread executes the same code but operates a different piece of data Each thread has its own context (i.e., can be treated/restarted/executed independently) A set of threads executing the same instruction are dynamically grouped into a warp (wavefront) by the hardware A warp is essentially a SIMD operation formed by hardware!

SPMD on SIMT Machine Warp: A set of threads that execute
for (i=0; i < N; i++) C[i] = A[i] + B[i]; load add store load add store Warp 0 at PC X Warp 0 at PC X+1 Warp 0 at PC X+2 Warp 0 at PC X+3 Iter. 1 Iter. 2 Warp: A set of threads that execute the same instruction (i.e., at the same PC) Realization: Each iteration is independent Idea: Programmer or compiler generates a thread to execute each iteration. Each thread does the same thing (but on different data) Can be executed on a MIMD machine This particular model is also called: SPMD: Single Program Multiple Data A GPU executes it using the SIMT model: Single Instruction Multiple Thread Can be executed on a SIMD machine

Graphics Processing Units SIMD not Exposed to Programmer (SIMT)

SIMD vs. SIMT Execution Model
SIMD: A single sequential instruction stream of SIMD instructions  each instruction specifies multiple data inputs [VLD, VLD, VADD, VST], VLEN SIMT: Multiple instruction streams of scalar instructions  threads grouped dynamically into warps [LD, LD, ADD, ST], NumThreads Two Major SIMT Advantages: Can treat each thread separately  i.e., can execute each thread independently (on any type of scalar pipeline)  MIMD processing Can group threads into warps flexibly  i.e., can group threads that are supposed to truly execute the same instruction  dynamically obtain and maximize benefits of SIMD processing

Multithreading of Warps
for (i=0; i < N; i++) C[i] = A[i] + B[i]; Assume a warp consists of 32 threads If you have 32K iterations, and 1 iteration/thread  1K warps Warps can be interleaved on the same pipeline  Fine grained multithreading of warps load add store load add store Warp 1 at PC X Warp 0 at PC X Warp 20 at PC X+2 Iter. 33 Iter. 1 Iter. 20*32 + 1 Iter. 2 Iter. 20*32 + 2 Iter. 34

Warps and Warp-Level FGMT
Warp: A set of threads that execute the same instruction (on different data elements)  SIMT (Nvidia-speak) All threads run the same code Warp: The threads that run lengthwise in a woven fabric … Thread Warp 3 Thread Warp 8 Common PC Thread Warp In SIMD, you need to specify the data array + an instruction (on which to operate the data on) + THE INSTRUCTION WIDTH. Eg: You might want to add 2 integer arrays of length 16, then a SIMD instruction would look like (the instruction has been cooked-up by me for demo) add.16 arr1 arr2 However, SIMT doesn't bother about the instruction width. So, essentially, you could write the above example as: arr1[i] + arr2[i] and then launch as many threads as the length of the array, as you want. Note that, if the array size was, let us say, 32, then SIMD EXPECTS you to explicitly call two such 'add.16' instructions! Whereas, this is not the case with SIMT. Scalar Scalar Scalar Scalar Thread Warp 7 Thread Thread Thread Thread W X Y Z SIMD Pipeline

High-Level View of a GPU

Latency Hiding via Warp-Level FGMT
Warp: A set of threads that execute the same instruction (on different data elements) Fine-grained multithreading One instruction per thread in pipeline at a time (No interlocking) Interleave warp execution to hide latencies Register values of all threads stay in register file FGMT enables long latency tolerance Millions of pixels Decode R F A L U D-Cache Thread Warp 6 Thread Warp 1 Thread Warp 2 Data All Hit? Miss? Warps accessing memory hierarchy Thread Warp 3 Thread Warp 8 Writeback Warps available for scheduling Thread Warp 7 I-Fetch SIMD Pipeline With a large number of shader threads multiplexed on the same execution resources, our architecture employs fine-grained multithreading where individual threads are interleaved by the fetch unit to proactively hide the potential latency of stalls before they occur. As illustrated by Figure, warps are issued fairly in a round-robin queue. When a thread is blocked by a memory request, shader core simply removes that thread’s warp from the pool of “ready” warps and thereby allows other threads to proceed while the memory system processes its request. With a large number of threads (1024 per shader core) interleaved on the same pipeline, FGMT effectively hides the latency of most memory operations since the pipeline is occupied with instructions from other threads while memory operations complete. also hides the pipeline latency so that data bypassing logic can potentially be omitted to save area with minimal impact on performance. simplify the dependency check logic design by restricting each thread to have at most one instruction running in the pipeline at any time. Slide credit: Tor Aamodt

Warp Execution (Recall the Slide)
32-thread warp executing ADD A[tid],B[tid]  C[tid] C[1] C[2] C[0] A[3] B[3] A[4] B[4] A[5] B[5] A[6] B[6] Execution using one pipelined functional unit C[4] C[8] C[0] A[12] B[12] A[16] B[16] A[20] B[20] A[24] B[24] C[5] C[9] C[1] A[13] B[13] A[17] B[17] A[21] B[21] A[25] B[25] C[6] C[10] C[2] A[14] B[14] A[18] B[18] A[22] B[22] A[26] B[26] C[7] C[11] C[3] A[15] B[15] A[19] B[19] A[23] B[23] A[27] B[27] Execution using four pipelined functional units Slide credit: Krste Asanovic

SIMD Execution Unit Structure
Functional Unit Lane Registers for each Thread Registers for thread IDs 0, 4, 8, … Registers for thread IDs 1, 5, 9, … Registers for thread IDs 2, 6, 10, … Registers for thread IDs 3, 7, 11, … Memory Subsystem Slide credit: Krste Asanovic

Warp Instruction Level Parallelism
Can overlap execution of multiple instructions Example machine has 32 threads per warp and 8 lanes Completes 24 operations/cycle while issuing 1 warp/cycle Load Unit Multiply Unit Add Unit W0 W1 W2 time W3 W4 W5 Warp issue Slide credit: Krste Asanovic

SIMT Memory Access Same instruction in different threads uses thread id to index and access different data elements Let’s assume N=16, 4 threads per warp  4 warps 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Threads + 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Data elements + + + + Warp 0 Warp 1 Warp 2 Warp 3 Slide credit: Hyesoon Kim

Sample GPU SIMT Code (Simplified)
CPU code for (ii = 0; ii < ; ++ii) { C[ii] = A[ii] + B[ii]; } CUDA code // there are threads __global__ void KernelFunction(…) { int tid = blockDim.x * blockIdx.x + threadIdx.x; int varA = aa[tid]; int varB = bb[tid]; C[tid] = varA + varB; } Slide credit: Hyesoon Kim

Sample GPU Program (Less Simplified)
Slide credit: Hyesoon Kim

Warp-based SIMD vs. Traditional SIMD
Traditional SIMD contains a single thread Sequential instruction execution; lock-step operations in a SIMD instruction Programming model is SIMD (no extra threads)  SW needs to know vector length ISA contains vector/SIMD instructions Warp-based SIMD consists of multiple scalar threads executing in a SIMD manner (i.e., same instruction executed by all threads) Does not have to be lock step Each thread can be treated individually (i.e., placed in a different warp)  programming model not SIMD SW does not need to know vector length Enables multithreading and flexible dynamic grouping of threads ISA is scalar  SIMD operations can be formed dynamically Essentially, it is SPMD programming model implemented on SIMD hardware

SPMD Single procedure/program, multiple data
This is a programming model rather than computer organization Each processing element executes the same procedure, except on different data elements Procedures can synchronize at certain points in program, e.g. barriers Essentially, multiple instruction streams execute the same program Each program/procedure 1) works on different data, 2) can execute a different control-flow path, at run-time Many scientific applications are programmed this way and run on MIMD hardware (multiprocessors) Modern GPUs programmed in a similar way on a SIMD hardware

SIMD vs. SIMT Execution Model
SIMD: A single sequential instruction stream of SIMD instructions  each instruction specifies multiple data inputs [VLD, VLD, VADD, VST], VLEN SIMT: Multiple instruction streams of scalar instructions  threads grouped dynamically into warps [LD, LD, ADD, ST], NumThreads Two Major SIMT Advantages: Can treat each thread separately  i.e., can execute each thread independently on any type of scalar pipeline  MIMD processing Can group threads into warps flexibly  i.e., can group threads that are supposed to truly execute the same instruction  dynamically obtain and maximize benefits of SIMD processing

Threads Can Take Different Paths in Warp-based SIMD
Each thread can have conditional control flow instructions Threads can execute different control flow paths B C D E F A G Thread Warp Common PC Thread 1 Thread 2 Thread 3 Thread 4 Slide credit: Tor Aamodt

Control Flow Problem in GPUs/SIMT
A GPU uses a SIMD pipeline to save area on control logic. Groups scalar threads into warps Branch divergence occurs when threads inside warps branch to different execution paths. Branch Path A Path B Branch Path A Path B This is the same as conditional/predicated/masked execution. Recall the Vector Mask and Masked Vector Operations? Slide credit: Tor Aamodt

Remember: Each Thread Is Independent
Two Major SIMT Advantages: Can treat each thread separately  i.e., can execute each thread independently on any type of scalar pipeline  MIMD processing Can group threads into warps flexibly  i.e., can group threads that are supposed to truly execute the same instruction  dynamically obtain and maximize benefits of SIMD processing If we have many threads We can find individual threads that are at the same PC And, group them together into a single warp dynamically This reduces “divergence”  improves SIMD utilization SIMD utilization: fraction of SIMD lanes executing a useful operation (i.e., executing an active thread)

Dynamic Warp Formation/Merging
Idea: Dynamically merge threads executing the same instruction (after branch divergence) Form new warps from warps that are waiting Enough threads branching to each path enables the creation of full new warps Warp X Warp Z Warp Y

Dynamic Warp Formation/Merging
Idea: Dynamically merge threads executing the same instruction (after branch divergence) Fung et al., “Dynamic Warp Formation and Scheduling for Efficient GPU Control Flow,” MICRO 2007. Branch Path A Path B Branch Path A

Dynamic Warp Formation Example
Execution of Warp x at Basic Block A Execution of Warp y Legend A B x/1110 y/0011 C x/1000 D x/0110 F x/0001 y/0010 y/0001 y/1100 A new warp created from scalar threads of both Warp x and y executing at Basic Block D D E x/1110 y/0011 G x/1111 y/1111 A A B B C C D D E E F F G G A A Baseline Time Dynamic Warp Formation A A B B C D E E F G G A A Time Slide credit: Tor Aamodt

Hardware Constraints Limit Flexibility of Warp Grouping
Functional Unit Lane Registers for each Thread Registers for thread IDs 0, 4, 8, … Registers for thread IDs 1, 5, 9, … Registers for thread IDs 2, 6, 10, … Registers for thread IDs 3, 7, 11, … Can you move any thread flexibly to any lane? Memory Subsystem Slide credit: Krste Asanovic

An Example GPU

NVIDIA GeForce GTX 285 NVIDIA-speak: 240 stream processors
“SIMT execution” Generic speak: 30 cores 8 SIMD functional units per core Slide credit: Kayvon Fatahalian

NVIDIA GeForce GTX 285 “core”
… 64 KB of storage for thread contexts (registers) 30 * 32 * 32 = 30 * 1024 = 30K fragments 64KB register file = bit registers per thread = 64B (1/32 that of LRB) 16KB of shared scratch 80KB / core available to software = SIMD functional unit, control shared across 8 units = instruction stream decode = multiply-add = execution context storage = multiply Slide credit: Kayvon Fatahalian

NVIDIA GeForce GTX 285 “core”
… 64 KB of storage for thread contexts (registers) To get maximal latency hiding: Run 1/32 of the time 16 words per thread = 64B Groups of 32 threads share instruction stream (each group is a Warp) Up to 32 warps are simultaneously interleaved Up to 1024 thread contexts can be stored Slide credit: Kayvon Fatahalian

30 cores on the GTX 285: 30,720 threads
NVIDIA GeForce GTX 285 Tex Tex … … … … Tex Tex … … Tex Tex … … Tex Tex If you’re running a CUDA program, and your not launching 30K threads, you are certainly not getting full latency hiding, and you might not be using the GPU well … … Tex Tex … … 30 cores on the GTX 285: 30,720 threads Slide credit: Kayvon Fatahalian

Introduction to GPGPU Programming
ETH Zürich Fall 2017 19 October 2017

Agenda for Today Traditional accelerator model
Program structure Bulk synchronous programming model Memory hierarchy and memory management Performance considerations Memory access SIMD utilization Atomic operations Data transfers New programming features Dynamic parallelism Collaborative computing

General Purpose Processing on GPU
GPUs have democratized HPC Great FLOP/$, massively parallel chip on a commodity PC However, this is not for free New programming model New challenges Algorithms need to be re-implemented and rethought Many workloads exhibit inherent parallelism Matrices Image processing Main bottlenecks CPU-GPU data transfers (PCIe, NVLINK) DRAM memory (GDDR5, HBM2)

CPU vs. GPU Different design philosophies
CPU: A few out-of-order cores GPU: Many in-order cores CPU: - Large caches: convert long latency memory accesses to short latency cache accesses. - Sophisticated control: branch predictions, data forwarding ALU: reduce operation latency GPU: Small caches to boost memory throughput Simple control Energy efficient ALUs: many, long latency but heavily pipelined for high throughput Require a huge number of threads to hide latencies Slide credit: Hwu & Kirk

GPU Computing Computation is offloaded to the GPU Three steps
CPU-GPU data transfer (1) GPU kernel execution (2) GPU-CPU data transfer (3)

Traditional Program Structure
CPU threads and GPU kernels Sequential or modestly parallel sections on CPU Massively parallel sections on GPU Serial Code (host) . . . Parallel Kernel (device) KernelA<<< nBlk, nThr >>>(args); Serial Code (host) . . . Parallel Kernel (device) KernelB<<< nBlk, nThr >>>(args); Slide credit: Hwu & Kirk

CUDA/OpenCL Programming Model
SIMT or SPMD Bulk synchronous programming Global (coarse-grain) synchronization between kernels The host (typically CPU) allocates memory, copies data, and launches kernels The device (typically GPU) executes kernels Grid (NDRange) Block (work-group) Within a block, shared memory and synchronization Thread (work-item)

Transparent Scalability
Hardware is free to schedule thread blocks Device Block 0 Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 Kernel grid Block 0 Block 1 Block 2 Block 3 Block 4 Block 5 Block 6 Block 7 Device Block 0 Block 1 Block 2 Block 3 time Block 4 Block 5 Block 6 Block 7 Each block can execute in any order relative to other blocks. Slide credit: Hwu & Kirk

CUDA/OpenCL Programming Model
Memory hierarchy

Traditional Program Structure
Function prototypes float serialFunction(…); __global__ void kernel(…); main() 1) Allocate memory space on the device – cudaMalloc(&d_in, bytes); 2) Transfer data from host to device – cudaMemCpy(d_in, h_in, …); 3) Execution configuration setup: #blocks and #threads 4) Kernel call – kernel<<<execution configuration>>>(args…); 5) Transfer results from device to host – cudaMemCpy(h_out, d_out, …); Kernel – __global__ void kernel(type args,…) Automatic variables transparently assigned to registers Shared memory – __shared__ Intra-block synchronization – __syncthreads(); as needed repeat Slide credit: Hwu & Kirk

CUDA Programming Language
Memory allocation cudaMalloc((void**)&d_in, #bytes); Memory copy cudaMemcpy(d_in, h_in, #bytes, cudaMemcpyHostToDevice); Kernel launch kernel<<< #blocks, #threads >>>(args); Memory deallocation cudaFree(d_in); Explicit synchronization cudaDeviceSynchronize();

Indexing and Memory Access
Image layout in memory height x width Image[j][i], where 0 ≤ j < height, and 0 ≤ i < width Image[0][1] Image[1][2]

Image layout in memory Row-major layout Image[j][i] = Image[j x width + i] Image[0][1] = Image[0 x 8 + 1] Image[1][2] = Image[1 x 8 + 2]

One GPU thread per pixel Grid of Blocks of Threads blockIdx.x, threadIdx.x gridDim.x, blockDim.x Thread 0 Thread 1 Thread 2 Thread 3 blockIdx.x Block 0 threadIdx.x Block 0 6 * = 25 blockIdx.x * blockDim.x + threadIdx.x

2D blocks gridDim.x, gridDim.y threadIdx.x = 1 threadIdx.y = 0 Block (0, 0) Row = blockIdx.y * blockDim.y + threadIdx.y blockIdx.x = 2 blockIdx.y = 1 Col = blockIdx.x * blockDim.x + threadIdx.x Row = 1 * = 3 Col = 0 * = 1 Image[3][1] = Image[3 * 8 + 1]

Brief Review of GPU Architecture
Streaming Processor Array Tesla architecture (G80/GT200)

Blocks are divided into warps SIMD unit (32 threads) Streaming Multiprocessors (SM) Streaming Processors (SP) Block 0’s warps Block 1’s warps Block 2’s warps … … … … … … t0 t1 t2 … t31 t0 t1 t2 … t31 t0 t1 t2 … t31

Streaming Multiprocessors (SM) Compute Units (CU) Streaming Processors (SP) or CUDA cores Vector lanes Number of SMs x SPs Tesla (2007): 30 x 8 Fermi (2010): 16 x 32 Kepler (2012): 15 x 192 Maxwell (2014): 24 x 128 Pascal (2016): 56 x 64 Volta (2017): 80 x 64

Performance Considerations
Main bottlenecks Global memory access CPU-GPU data transfers Memory access Latency hiding Thread Level Parallelism (TLP) Occupancy Memory coalescing Data reuse Shared memory usage SIMD Utilization Atomic operations Data transfers between CPU and GPU Overlap of communication and computation

Latency Hiding Occupancy: ratio of active warps
Not only memory accesses (e.g., SFU) 4 active warps 2 active warps

Occupancy SM resources (typical values) Occupancy calculation
Maximum number of warps per SM (64) Maximum number of blocks per SM (32) Register usage (256KB) Shared memory usage (64KB) Occupancy calculation Number of threads per block Registers per thread Shared memory per block The number of registers per thread is known in compile time

Memory Coalescing When accessing global memory, peak bandwidth utilization occurs when all threads in a warp access one cache line Not coalesced Coalesced Md Nd Thread 1 H T D Thread 2 I W WIDTH Slide credit: Hwu & Kirk

Memory Coalescing Coalesced accesses T1 T2 T3 T4
Time Period 1 Time Period 2 Access direction in Kernel code … Slide credit: Hwu & Kirk

Memory Coalescing Uncoalesced accesses T1 T2 T3 T4
Time Period 1 Time Period 2 Access direction in Kernel code … Slide credit: Hwu & Kirk

Memory Coalescing AoS vs. SoA

Memory Coalescing Linear and strided accesses GPU CPU
AMD Kaveri A K

Data Reuse Same memory locations accessed by neighboring threads
for (int i = 0; i < 3; i++){ for (int j = 0; j < 3; j++){ sum += gauss[i][j] * Image[(i+row-1)*width + (j+col-1)]; }

Data Reuse Shared memory tiling
__shared__ int l_data[(L_SIZE+2)*(L_SIZE+2)]; … Load tile into shared memory __syncthreads(); for (int i = 0; i < 3; i++){ for (int j = 0; j < 3; j++){ sum += gauss[i][j] * l_data[(i+l_row-1)*(L_SIZE+2)+j+l_col-1]; }

Shared Memory Shared memory is an interleaved memory
Typically 32 banks Each bank can service one address per cycle Successive 32-bit words are assigned to successive banks Bank = Address % 32 Bank conflicts are only possible within a warp No bank conflicts between different warps

Shared Memory Bank conflict free Bank 15 Bank 7 Bank 6 Bank 5 Bank 4
Thread 15 Thread 7 Thread 6 Thread 5 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Bank 15 Bank 7 Bank 6 Bank 5 Bank 4 Bank 3 Bank 2 Bank 1 Bank 0 Thread 15 Thread 7 Thread 6 Thread 5 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Linear addressing: stride = 1 Random addressing 1:1 Slide credit: Hwu & Kirk

Shared Memory N-way bank conflicts Thread 15 Thread 7 Thread 6
x8 Thread 11 Thread 10 Thread 9 Thread 8 Thread 4 Thread 3 Thread 2 Thread 1 Thread 0 Bank 15 Bank 7 Bank 6 Bank 5 Bank 4 Bank 3 Bank 2 Bank 1 Bank 0 2-way bank conflict: stride = 2 8-way bank conflict: stride = 8 Slide credit: Hwu & Kirk

Shared Memory Bank conflicts are only possible within a warp
No bank conflicts between different warps If strided accesses are needed, some optimization techniques can help Padding Hash functions

SIMD Utilization Intra-warp divergence Compute(threadIdx.x);
if (threadIdx.x % 2 == 0){ Do_this(threadIdx.x); } else{ Do_that(threadIdx.x);

SIMD Utilization Intra-warp divergence Compute(threadIdx.x);
if (threadIdx.x < 32){ Do_this(threadIdx.x * 2); } else{ Do_that((threadIdx.x%32)*2+1);

Vector Reduction Naïve mapping 1 2 3 4 5 7 6 10 9 8 11 0+1 2+3 4+5 6+7
1 2 3 4 5 7 6 10 9 8 11 0+1 2+3 4+5 6+7 10+11 8+9 0...3 4..7 8..11 0..7 8..15 iterations Thread 0 Thread 8 Thread 2 Thread 4 Thread 6 Thread 10 Slide credit: Hwu & Kirk

Vector Reduction Naïve mapping __shared__ float partialSum[]
unsigned int t = threadIdx.x; for (int stride = 1; stride < blockDim.x; stride *= 2) { __syncthreads(); if (t % (2*stride) == 0) partialSum[t] += partialSum[t + stride]; }

Vector Reduction Divergence-free mapping 1 2 3 … 13 15 14 18 17 16 19
Thread 0 1 2 3 … 13 15 14 18 17 16 19 0+16 15+31 4 Thread 1 Thread 2 Thread 14 Thread 15 iterations Slide credit: Hwu & Kirk

Vector Reduction Divergence-free mapping __shared__ float partialSum[]
unsigned int t = threadIdx.x; for (int stride = blockDim.x; stride > 1; stride >> 1){ __syncthreads(); if (t < stride) partialSum[t] += partialSum[t + stride]; }

We did not cover the following slides in lecture
We did not cover the following slides in lecture. These are for your preparation for the next lecture.

Atomic Operations Shared memory atomic operations
CUDA: int atomicAdd(int*, int); PTX: atom.shared.add.u32 %r25, [%rd14], %r24; SASS: Tesla, Fermi, Kepler Maxwell /*00a0*/ LDSLK P0, R9, [R8]; IADD R10, R9, R7; STSCUL P1, [R8], R10; BRA 0xa0; /*01f8*/ ATOMS.ADD RZ, [R7], R11; Native atomic operations for 32-bit integer, and 32-bit and 64-bit atomicCAS

Atomic Operations Atomic conflicts
Intra-warp conflict degree from 1 to 32 tbase tconflict Shared memory Shared memory tbase No atomic conflict = concurrent updates Atomic conflict = serialized updates

Histogram Calculation
Histograms count the number of data instances in disjoint categories (bins) for (each pixel i in image I){ Pixel = I[i] // Read pixel Pixel’ = Computation(Pixel) // Optional computation Histogram[Pixel’]++ // Vote in histogram bin } Atomic additions

Frequent conflicts in natural images

Privatization: Per-block sub-histograms in shared memory Block 0’s sub-histo Block 1’s sub-histo Block 2’s sub-histo Block 3’s sub-histo Shared memory Global memory Final histogram

Data Transfers Synchronous and asynchronous transfers
Streams (Command queues) Sequence of operations that are performed in order CPU-GPU data transfer Kernel execution D input data instances, B blocks GPU-CPU data transfer Default stream Computation is divided such that if D data instances need B blocks to be processed… The kernel is therefore nStreams times launched. CUDA literature gives only two rough estimates, but does not give any hint of the optimal number of streams in which a given data set should be preferably divided.

Asynchronous Transfers
Computation divided into nStreams D input data instances, B blocks nStreams D/nStreams data instances B/nStreams blocks Estimates Computation is divided such that if D data instances need B blocks to be processed… The kernel is therefore nStreams times launched. CUDA literature gives only two rough estimates, but does not give any hint of the optimal number of streams in which a given data set should be preferably divided. tE >= tT (dominant kernel) tT > tE (dominant transfers)

Asynchronous Transfers
Overlap of communication and computation (e.g., video processing) A number b of blocks per frame executes. Data transfers are overlapped with computation. Thus, some time can be saved.

Summary Traditional accelerator model Program structure
Bulk synchronous programming model Memory hierarchy and memory management Performance considerations Memory access Latency hiding: occupancy (TLP) Memory coalescing Data reuse: shared memory SIMD utilization Atomic operations Data transfers

Computer Architecture Lecture 9: GPUs and GPGPU Programming
Prof. Onur Mutlu ETH Zürich Fall 2017 19 October 2017

Computer Architecture Lecture 9: GPUs and GPGPU Programming

Similar presentations

Presentation on theme: "Computer Architecture Lecture 9: GPUs and GPGPU Programming"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Computer Architecture Lecture 9: GPUs and GPGPU Programming

Similar presentations

Presentation on theme: "Computer Architecture Lecture 9: GPUs and GPGPU Programming"— Presentation transcript:

Similar presentations

About project

Feedback