GPU存储模型

写在前面

其实我对这篇博客的名字思考了一下。我是应该叫它GPU的存储模型呢,还是应该叫它CUDA的存储模型呢。在我看来其实都是可以的,cuda并行的三个机构单元grid、block、threads其实和GPU上的SM,SP(对于threads的话是需要靠wrap的调度实现的和SP不是严格对应的)都是可以对应起来的,可以看作是一种映射的关系。虽然为了减少latency需要保证有足够多的activate block来给SM,具体执行的时候是程序员无法控制的(也就是无法控制treads的具体执行顺序,这是由硬件进行调度的,当然我们可以通过同步机制来控制线程),但是至少在一个具体的时间点上这些逻辑上的并行单元和硬件单元还是可以一一对应起来的。因此这里选择了这样的名字,文中的图片中可能会有以上的两种前后映射的关系,都说的都是一件事。

存储模型

首先对于GPU这样的设备进行并行编程,是需要操控大量的线程的,其实是可以看作是一种人海战术。我们可以展开联想,早期的人海战术虽然可以解决战斗,但是损伤是很大的,映射过来也就是说GPU的能量消耗很大。但是将工业时代的流水线模式借鉴过来,虽然还是人海战术,但是是精密管理的人海战术,在完成任务的时候损失就会明显变少。这其实在GPU架构的发展上是可以看出端倪的,无论是SM中的WRAP调度,从单WRAP到多WRAP,还是SM中管理层的增加,管理更加精细,控制能耗的能力更强,我们心里需要有个谱,就是GPU这东西没有那么民主,管理不是扁平化的,恰恰相反,GPU的管理是很好的分层管理,层层到位的,管理是这样,存储的模型也是这样的。有很多层级,每个层级的访问速度有可能相差很大,这也是前面所讲的,为了减少存储墙做的努力,可能对于threads而言,命中cache和我们中了彩票一样开心吧!一切都是为了减少latency,更充分高效的使用设备。

从上面的图片中我们可以看到,对一个GRID而言的GPU部分被分成了很多机构。这里首先观察处理一个block的SM的存储结构,