Chang_JH

Nvidia ＜cuda programming guide＞文章转载

CUDA官方文档转接

参考cuda toolkit documentation

一、简介

GPU将更多晶体管用于数据计算，而CPU将更多晶体管用于流管理。
GPU通过用计算掩盖访存延迟，而CPU采用大容量的cache和复杂的流处理。

1.1 可扩展编程模型

利用多核处理器如GPU的编程面临的问题是：如何透明地利用日益增长的核数。
cuda提供了一个简单的编程模型，而又能解决上述问题的方法。

核心分为三个关键抽象：
- 线程组织层级结构。
- 共享内存。
- 阻碍同步。
保留了线程协作的表达性，但是提供了自动扩展的能力。
线程block可以放到任何SM上运行。

图1. 自动扩展性

block间执行的隔离性使得每个block并不在乎在哪个SM上运行，所以当硬件SM数量比较多时，可以同时运行多个block，当SM数量较小时，block之间可以排队等待在一个SM上运行。自动扩展性的由来。

二、CUDA编程模型

2.1 kernel

2.2 线程层级结构

2.3 memory hierarchy

2.4 异构编程

三、编程接口

3.1编译模型

3.1.1 编译工作流–离线编译

分离主机代码和设备代码。
将设备代码编译成汇编格式(PTX code)或二进制格式(cubin object)。
修改主机代码，将<<<...>>>语法替换成必要的CUDA runtime function calls。来启动 PTX格式代码或者cubin object。
剩下的C++代码要么交给其他要么交给nvcc去编译。

3.1.2 编译工作流–即时编译

系统运行时加载PTX code。
被driver编译成二进制文件。
通过**CUDA Environment Variables**可以控制CUDA编译时的操作。

3.2 CUDA运行时

在cudart库中实现，要么通过cudart.lib、libcudart.a或者cudart.dll或libcudart.so。

连接到同一个cuda runtime instance的组件之间传递cuda runtime symbol的地址才是安全的。

3.2.1 CUDA Runtime初始化

cuda runtime没有显式的初始化函数，当调用第一个runtime函数时才会初始化一个runtime instance。
runtime为系统中每个设备创建一个上下文(context)。
- 这一个context被称为primary context：在第一次调用需要active context的接口时创建。
- 此应用上所有线程共享此primary context。
- 创建primary context时，如果必要，device code被JIT编译，然后上传至device memory。
以上操作是透明的，如果需要，可以通过driver API获得。
当线程调用cudaDeviceReset()时，它将销毁它current work on的primary context。
- 任何线程再在此设备上调用runtime function时会重新创建一个primary context。
CUDA interface使用global state：
- global state程序启动时初始化
- global state程序销毁时销毁
- CUDA runtime和driver无法检测global state的可用性，任何在global state可用范围外的调用都导致Undefined behavior。

Context：(具体看J.1节)

参考stackoverflow问答

所有在driverAPI中的资源和动作，都包含在一个CUDA 上下文中。
除了模块、纹理和表面引用，每个context拥有它们自己的地址空间。

3.2.2 设备内存

设备内存可以以_线性内存_和_CUDA 数组_。

CUDA 数组

cuda数组是为纹理拉取优化的不公开数据结构。

线性内存

分配在单一的统一地址空间内。可以用指针相互引用。

地址空间的大小取决于主机结构和GPU计算能力。

	x86_64 (AMD64)	POWER (ppc64le)	ARM64
up to compute capability 5.3 (Maxwell)	40bit	40bit	40bit
compute capability 6.0 (Pascal) or newer	up to 47bit	up to 49bit	up to 48bit

3.2.4 共享内存

shared memory比global memory更快。

3.2.6 并行执行

以下的任务可以相互间并发进行：

主机上的计算
设备上的计算
从主机到设备内存传输
从设备到主机内存传输
一个设备内部内存传输
设备间内存传输

3.2.6.1 主机和设备间并行

从主机的角度来看，以下操作是异步的：

启动kernel
一个设备内部内存传输
从主机到设备的小于64KB的内存传输
Async结尾的内存操作函数
设备内存操作

设置CUDA_LAUNCH_BLOCKING变量可以使设备一时间只运行一个kernel，用于debug。

kernel启动在有分析器时是同步的，除非支持异步分析器。

Async函数可能也会因为涉及not page-locked内存而同步起来。

3.2.6.2 并行kernel 执行

并发的kernel必须在同一context中。
能同时运行的kernel数量受GPU规格限制。

3.2.6.3 数据传输与kernel执行并行

检查asyncEngineCount可以看出来是否支持异步并行。
在同一设备间的内存拷贝也可以并行。
主机内存必须是page-locked才能被Async函数使用。

3.2.6.4 并行数据传输

数据传输到，出设备可以并行
涉及到的内存只能是page-locked。

3.2.6.5 流

应用通过streams管理上述的并行操作。
stream就是将一系列操作(可能由不同主机线程提出)顺序执行。
不同流之间的command顺序不能保证。
当前置条件满足时，stream中的任务会被执行。
synchronize调用的成功暗示前面的命令都已经执行完了。

3.2.6.5.1 创建与销毁

一个stream通过一个stream obj定义
可以将stream obj当做一个参数传递给kernel launch或内存传输操作。

cudaStream_t stream[2];
for(int i =0 ; i < 2; i++){
    cudaStreamCreate(&stream[i]);
}
// destruction
for(int i =0;i< 2; i++){
    cudaStreamDestroy(stream[i]);
}
// cudaStreamDestroy会如此工作：立刻返回成功
// 如果还有工作在这个stream上做，会等它们做完自动返回

3.2.6.5.2 default stream

没有指定stream、或者设置stream参数为0，会被认为是默认stream。

编译时--default-stream legacy会让主机所有线程共享一个默认stream，NULL Stream。
- 每个设备有一个NULL stream，被所有host threads所用。
- 不加--default-streamflag时的默认情况
编译时--default-stream per-thread，default stream是一个普通stream，并且每个线程都有自己的default stream。

null stream上的命令这样调度(设备角度上的同步)参考nvidia default_stream：

当设备上所有其他stream的命令都执行完了，才能运行NULLstream上的command
NULL stream上必须在其他stream上的命令开始前完成。

3.2.6.5.3 显式同步

有许多显式streams间同步的方法。

cudaDeviceSynchronize()等待所有主机线程的所有stream的前置任务都完成了。

cudaStreamSynchronize()将stream作为参数，等待，直到给定stream上所有之前的命令都执行完了。

cudaStreamWaitEvent()将stream和event作为参数，event之后的调用都被阻塞了。

cudaStreamQuery()让应用可以知道一个stream中的明林是否都已经执行完了。

3.2.6.5.4 隐式同步

两个stream中的指令不可执行，当他们中某个执行在做下面的事：

主机page-locked内存分配
设备内存分配
设备内存set，memset
设备内部内存拷贝
NULL stream上的CUDA指令
a switch between the L1/shared memory configurations described in Compute Capability 3.x and Compute Capability 7.x.

支持kernel并发执行的设备上，任何需要依赖检查(判定一个streamed kernel是否完成)的操作，

只有当所有先前启动的所有stream中的kernel的所有block都启动运行了，才能开始执行。
阻塞所有接下来kernel启动，直到被检查的kernel启动完成了。

需要依赖检查的操作包括:

在这个stream中所有启动需要检查的commands
所有在这个stream上调用的cudaStreamQuery()

因此应用如果想要提升kernel并发的性能，需要：

所有独立的操作应该在不独立的操作前完成
尽可能减少同步调用。

3.2.6.5.5 掩盖操作

3.2.6.5.6 调用主机程序(callback)

通过将cudaLaunchHostFunc()压入stream中，当它之前的所有命令都执行完了(kernel运行完、内存拷贝完等)，它就会被调用。
它之后的stream中的命令也会等cudaLaunchHostFunc()执行完后才能运行。
指定的回调函数不能使用cudaAPI，否则会造成循环等待。

3.2.6.5.7 stream优先级

可以使用cudaStreamCreateWithPriority()来创建带有优先级的stream。

通过cudaDeviceGetStreamPriorityRange()可以获取优先级。

高优先级的stream会提前工作。

4. 硬件实现

NVIDIA的GPU架构是建立在可扩展的SM组上。当host上的程序调用了一个kernel，blocks of the grid会被枚举，并且分发到不同的SM上（如果SM能支撑起运算）。

一个block的所有线程会在一个SM上同时执行(warp替换)。
多个block可以一个SM上同时执行。
- 当有block终结，会有新的block在这个SM上启动。

4.1 SIMT 架构

当一个SM获得一个block要执行时，SM将block划分成warps，并且每个warp通过_warp scheduler_单独调度。
一个warp一次执行一个指令，如果warp内线程出现分支，那么warp会解决分支。
- 处理分支只发生在warp内，warp间是独立运行的。

4.2 硬件多线程

每个warp的上下文context都被SM on-chip地维护，在warp的整个生命周期。
- 因此从一个warp的context切换到另一个没有影响。
- warp scheduler选取已经可以运行的warp进行执行。
每个SM都有一组32位的寄存器，被warps划分(partition)占有，生命周期内不释放。
并行data cache和shared memory被blocks划分占有，生命周期内不释放。

以上，

SM运行一个kernel时，可同时reside、process的block数量和warp数量由下列因素决定：

kernel使用的寄存器数量、共享内存使用量（独享SM时理想值）。
实际上SM可用的寄存器数量以及共享内存数量（现实SM的限制）。

最后
SM对reside的warps和block数量限制。

计算能力(compute capability)由这些原因构成：SM对reside的warps、blocks数量的限制，以及寄存器数量、共享内存数量等。

假如没有任何一个SM能执行kernel的一个block，那么kernel会启动失败。

为一个block分配的寄存器数量、和共享内存数量，在CUDA Occupancy Calculator中可以查看。

B.2 变量空间指示符

变量空间指示符指明了变量在设备上的位置。

没有__device__ __shared__ __constant__描述的，一般都在寄存器上。

B.2.1 device

指明一个变量在设备上。

在global内存空间。
生命周期与创建它的CUDA context一样长。
每个设备有不同的对象
可以被grid中所有线程访问到，主机可以通过cudaGetSymbolAddress()、cudaGetSymbolSize()、cudaMemcpyToSymbol()、cudaMemcpyFromSymbol()访问。

B.2.2 constant

选择性地与__device__合用，描述这样的变量：

在常量内存空间。
与创建它的context生命周期一样长。
每个设备中有不同的对象。
可以被grid中所有线程访问到，主机可以通过cudaGetSymbolAddress()、cudaGetSymbolSize()、cudaMemcpyToSymbol()、cudaMemcpyFromSymbol()访问。

B.2.3 shared