CUDA内核启动参数解释对了吗？

Question

在这里，我尝试使用一些伪代码自我解释CUDA启动参数模型（或执行配置模型），但我不知道是否有一些重大错误，所以希望有人帮助审查它，并给我一些建议。 谢谢先进。

这里是：

/*
  normally, we write kernel function like this.
  note, __global__ means this function will be called from host codes,
  and executed on device. and a __global__ function could only return void.
  if there's any parameter passed into __global__ function, it should be stored
  in shared memory on device. so, kernel function is so different from the *normal*
  C/C++ functions. if I was the CUDA authore, I should make the kernel function more
  different  from a normal C function.
*/

__global__ void
kernel(float *arr_on_device, int n) {
        int idx = blockIdx.x * blockDIm.x + threadIdx.x;
        if (idx < n) {
                arr_on_device[idx] = arr_on_device[idx] * arr_on_device[idx];
        }
}

/*
  after this definition, we could call this kernel function in our normal C/C++ codes !!
  do you feel something wired ? un-consistant ?
  normally, when I write C codes, I will think a lot about the execution process down to
  the metal in my mind, and this one...it's like some fragile codes. break the sequential
  thinking process in my mind.
  in order to make things normal, I found a way to explain: I expand the *__global__ * function
  to some pseudo codes:
*/

#define __foreach(var, start, end) for (var = start, var < end; ++var)

__device__ int
__indexing() {
        const int blockId = blockIdx.x * gridDim.x + gridDim.x * gridDim.y * blockIdx.z;

        return 
                blockId * (blockDim.x * blockDim.y * blockDim.z) +
                threadIdx.z * (blockDim.x * blockDim.y) +
                threadIdx.x;
}

global_config =:
        {
                /*
                  global configuration.
                  note the default values are all 1, so in the kernel codes,
                  we could just ignore those dimensions.
                 */ 
                gridDim.x = gridDim.y = gridDim.z = 1;
                blockDim.x = blockDim.y = blockDim.z = 1;
        };

kernel =:
        {
                /*
                  I thought CUDA did some bad evil-detail-covering things here.
                  it's said that CUDA C is an extension of C, but in my mind,
                  CUDA C is more like C++, and the *<<<>>>* part is too tricky.
                  for example:
                  kernel<<<10, 32>>>(); means kernel will execute in 10 blocks each have 32 threads.

                  dim3 dimG(10, 1, 1);
                  dim3 dimB(32, 1, 1);
                  kernel<<<dimG, dimB>>>(); this is exactly the same thing with above.

                  it's not C style, and C++ style ? at first, I thought this could be done by
                  C++'s constructor stuff, but I checked structure *dim3*, there's no proper
                  constructor for this. this just brroke the semantics of both C and C++. I thought
                  force user to use *kernel<<<dim3, dim3>>>* would be better. So I'd like to keep
                  this rule in my future codes.
                */

                gridDim  = dimG;
                blockDim = dimB;

                __foreach(blockIdx.z,  0, gridDim.z)
                __foreach(blockIdx.y,  0, gridDim.y)
                __foreach(blockIdx.x,  0, gridDim.x)
                __foreach(threadIdx.z, 0, blockDim.z)
                __foreach(threadIdx.y, 0, blockDim.y)
                __foreach(threadIdx.x, 0, blockDim.x)
                {
                        const int idx = __indexing();        
                        if (idx < n) {
                                arr_on_device[idx] = arr_on_device[idx] * arr_on_device[idx];
                        }
                }
        };

/*
  so, for me, gridDim & blockDim is like some boundaries.
  e.g. gridDim.x is the upper bound of blockIdx.x, this is not that obvious for people like me.
 */

/* the declaration of dim3 from vector_types.h of CUDA/include */
struct __device_builtin__ dim3
{
        unsigned int x, y, z;
#if defined(__cplusplus)
        __host__ __device__ dim3(unsigned int vx = 1, unsigned int vy = 1, unsigned int vz = 1) : x(vx), y(vy), z(vz) {}
        __host__ __device__ dim3(uint3 v) : x(v.x), y(v.y), z(v.z) {}
        __host__ __device__ operator uint3(void) { uint3 t; t.x = x; t.y = y; t.z = z; return t; }
#endif /* __cplusplus */
};

typedef __device_builtin__ struct dim3 dim3;

Answer 1

CUDA DRIVER API

CUDA Driver API v4.0及更高版本使用以下函数来控制内核启动：

cuFuncSetCacheConfig
cuFuncSetSharedMemConfig
cuLaunchKernel

在v4.0中引入cuLaunchKernel之前，使用了以下CUDA驱动程序API函数。

cuFuncSetBlockShape()
cuFuncSetSharedSize()
cuParamSet{Size,i,fv}()
cuLaunch
cuLaunchGrid

有关这些功能的更多信息，请参阅cuda.h.

CUresult CUDAAPI cuLaunchKernel(CUfunction f,
    unsigned int gridDimX,
    unsigned int gridDimY,
    unsigned int gridDimZ,
    unsigned int blockDimX,
    unsigned int blockDimY,
    unsigned int blockDimZ,
    unsigned int sharedMemBytes,
    CUstream hStream,
    void **kernelParams,
    void **extra);

cuLaunchKernel将整个启动配置作为参数。

有关详细信息，请参阅NVIDIA驱动程序API [执行控制] 1 。

CUDA KERNEL发布

cuLaunchKernel将1.验证启动参数2.更改共享内存配置3.更改本地内存分配4.将流同步令牌推入命令缓冲区以确保流中的两个命令不重叠4.推送启动参数进入命令缓冲区5.将启动命令推入命令缓冲区6.将命令缓冲区提交给设备（在wddm驱动程序上，此步骤可能会延迟）7。在wddm上，内核驱动程序将分页设备内存中所需的所有内存

GPU将1.验证命令2.将命令发送到计算工作分配器3.将启动配置和线程块分派给SM

当所有线程块都已完成时，工作分配器将刷新缓存以遵守CUDA内存模型，并将内核标记为已完成，以便流中的下一个项目可以进行前进。

调度线程块的顺序因架构而异。

计算能力1.x设备将内核参数存储在共享内存中。 计算能力2.0-3.5设备将kenrel参数存储在常量存储器中。

CUDA RUNTIME API

CUDA Runtime是CUDA驱动程序API之上的C ++软件库和构建工具链。 CUDA Runtime使用以下函数来控制内核启动：

cudaConfigureCall cudaFuncSetCacheConfig cudaFuncSetSharedMemConfig cudaLaunch cudaSetupArgument

请参阅NVIDIA Runtime API [执行控制] 2

<<< >>> CUDA语言扩展是用于启动内核的最常用方法。

在编译期间，nvcc将为使用<<< >>>调用的每个内核函数创建一个新的CPU存根函数，它将用对stub函数的调用替换<<< >>>。

例如

__global__ void kernel(float* buf, int j)
{
    // ...
}

kernel<<<blocks,threads,0,myStream>>>(d_buf,j);

生成

void __device_stub__Z6kernelPfi(float *__par0, int __par1){__cudaSetupArgSimple(__par0, 0U);__cudaSetupArgSimple(__par1, 4U);__cudaLaunch(((char *)((void ( *)(float *, int))kernel)));}

您可以通过在您的nvcc命令行中添加--keep来检查生成的文件。

cudaLaunch调用cuLaunchKernel。

CUDA DYNAMIC PARALLELISM

CUDA CDP的工作方式与上述CUDA Runtime API类似。

Answer 2

通过使用<<<...>>> ，您将在GPU中启动许多线程。 这些线程被分组为块并形成一个大网格。 所有线程都将执行调用的内核函数代码。

在内核函数中，内置变量（如threadIdx和blockIdx使代码知道它运行的是哪个线程并执行工作的预定部分。

编辑

基本上， <<<...>>>简化了启动内核的配置过程。 如果不使用它，可能需要为单个内核启动调用4~5个API，就像OpenCL方式一样，它只使用C99语法。

实际上，您可以检查CUDA驱动程序API。 它可能提供所有这些API，因此您不需要使用<<<>>> 。

Answer 3

基本上，GPU被分为单独的“设备”GPU（例如GeForce 690有2个） - >多个SM（流式多处理器） - >多个CUDA核心。 据我所知，块或网格的维数只是与硬件无关的逻辑分配，但块的总大小 （x * y * z）非常重要。

块中的线程必须位于同一SM上，才能使用其共享内存和同步功能。 因此，您不能拥有包含更多线程的块，而不是包含在SM中的CUDA核心。

如果我们有一个简单的场景，我们有16个SM，每个有32个CUDA核心，并且我们有31x1x1块大小和20x1x1网格大小，我们将至少丧失卡的处理能力的1/32。 每次运行一个块时，SM的32个核心中只有31个忙。 块将加载以填充SM，我们将在大约相同的时间内完成16个块，并且当前4个SM释放时，它们将开始处理最后4个块（不一定是块＃17-20）。

欢迎提出意见和更正。