GPU硬件架构图

发表于 | 分类于 | |
字数统计: 1,863 | 阅读时长 ≈ 7

引言

最近在搞GPU，往简单了说，GPU实际上就是在画三角形，往复杂了说，他的各种并行操作，各个渲染阶段几本书都讲不清楚。这大概也就是为什么能做好GPU的整个星球上也没有几家的原因吧。本文我们尝试从简化的架构来了解一下GPU的各个模块以及相应的工作原理。

首先先抛个图，下图就是Nvidia Turing102 GPU的一个组件架构图，可以看到密密麻麻的SM和RT Core，这两个组件实际上算是GPU的一个基本的工作单元，当然RT Core是引入光线追踪后出现的单元，早期的一些架构是不存在这一单元的。下图不是很清晰，可以查看NVIDIA-Turing-Architecture-Whitepaper来获取更加清晰的图像。

NVIDIATuring

下面我们开始从逻辑渲染管线，以及架构图的各个组件的功能开始，一步一步的来解析GPU的架构逻辑

GPU的逻辑管线

现在GPU的发展，早已经不是最初的几个硬件实现一下加速功能而已，它有着复杂的逻辑，因此希望开发者按照GPU的物理管线进行编程是不现实的，同时由于水平以及理解的差异，必将导致效率良莠不齐，因此GPU实现了一套逻辑的管线，开发者只需要按照逻辑管线的规则进行操作即可。

NVIDIALogicPipeline

  • 当我们需要渲染时，我们实际上会给GPU下一些指令，比如drawCall/bindBuffer等等，这些指令都属于Graphics API。
  • 驱动程序则会将这些API编码到pushBuffer中。
  • 当我们显示掉哟个flush或者pushBuffer指令积攒到一定时，驱动会批量将pushBuffer中的指令传送到GPU。
  • GPU的Host Interface会拾取这些指令，然后交由Front End来处理
  • Primitive Distributor负责分配任务，什么任务呢？就是将三角形分配给各个GPC（这里我们先不必理会GPC是什么）
  • Crossbar来进行GPC之间的工作转移以及其他单元的通信，比如ROP（Render Output Unit）
  • 通过vs（vertex shader）和GS（Geometry shader）来进行shader的操作，然后做视口的变换（也就是viewport Transform）
  • 随后光栅化器会做光栅化
  • Attribute Setup保证了从vs来的数据经过插值后是pixel-shade是可读的
  • PS用来做pixel shader（也叫做fragment shader）, 用来给光栅化后的pixel着色
  • ROP会做blend，depth test等操作，保证最终的着色结果正确，然后将渲染结果输出到FB(FrameBuffer)

上面就是GPU渲染的一个逻辑工作流程。

GPU的架构以及相应的组件

还是从我们最开始的那张架构图说起

NVIDIATuring

  • PCI Express Host Interface 是主机与GPU的接口，用于主机与GPU的通讯交互
  • GigaThread Engine 负责GPU所有工作的管理
  • Memory Controller 两侧的12个存储控制器用来管理显存，它连接着L2 Cache和ROP unit, 下图中的蓝色小框就是ROP unit
    ROP_L2Cache

  • GPC 在图中我们可以看到一共有6个GPC，GPC是Graphics Processing Cluster，图形处理簇，具体的图形渲染业务就是在GPC中进行。我们也能看出来，复杂的unit都在GPC中呢。
    GPC

    • 每个GPC里面有一个光栅化引擎，这个是用来做光栅化的

    • TPC 纹理处理簇， 每个GPC包含有6个TPC

      • PolyMorph Engine 多边形引擎，它负责属性装配（attribute Setup）、顶点拉取(VertexFetch)、曲面细分
      • SM（Streaming Multiprocessor） 流处理器， shader的执行就是在SM上进行的。这是一个非常重要的组件，下面我们会主要分析

PolyMorph Engine 多边形引擎

实际上这个里面包含了多个组件，如下所示：
ROP_L2Cache

  • vertex Fetch 负责顶点获取
  • Tessellator负责曲面细分
  • viewport Transform负责视口变换
  • Attribute Setup负责属性装配
  • stream Output负责输出

SM（Streaming Multiprocessor）

这里我们单拿出来SM来分析，因为SM内部也是很复杂的，也有很多不一样的东西，下面是SM的结构图

SM

  • Warp Scheduler 用来管理Warp（先不用管这是啥，下面会解释）
  • Dispatch Unit 用来执行指令
  • Register File 用来存储Register
  • INT32 用于整形计算的core
  • FP32 用于浮点数据的计算core
  • Tensor Core 用来做矩阵运算的，在深度学习中会加速运算
  • LD/ST(Load/Store) 也就是读取单元
  • L1 Cache L1缓存
  • Tex 纹理读取单元
  • RT Core 光线追踪的，这里暂不介绍
  • SFU（Special function units）执行特殊数学运算（sin、cos、log等）

下面我们来详细分析下SM：

我们知道GPU的运行逻辑是SIMD(Single Instructure Multiple Data)，这就是在SM中实现的。SM中有很多的core，这些core可以执行计算。SM就负责Shader的执行。

SM从GigaThread Engine接收到大线程块，然后将其拆分为更小的堆，每个堆包含32个线程，这样的堆就被称之为Warp。一个Maxwell架构的SM最多可以容纳64个Warp。对于Maxwell的GPU, 一个SP（SMM）有4个Warp Scheduler, 每个Warp Scheduler可以处理一个Warp，并管理SM上剩余的Warp。

Maxwell

对于每个Core来说，它是不认识shader的，它每次只能看到一条指令，而且是32个core只能同时看到同一条指令。因此SM会给32个core下发同一条指令，所有的core均执行这提供一条指令，但是分配到不同core上的顶点数据可是不一样的，这样如果shader中存在if条件的话，就有可能存在一部分core在执行，一部分core在休息的场景。因此在shader中，if的存在对于并行度来说是个极大的挑战。

不可能存在说一部分 Core 在执行指令 A 的时候，另一部分 Core 却在执行指令 B。这种执行机制被称为 锁步（lock-step），这也是GPU的基础。

总的来说SM负责shader的执行，它接受指令，利用锁步（lock-step）机制，实现指令的并行处理。

还有一点，我们的Maxwell的SP明明只能同时执行4个Warp，为何还要一个让其容纳64个Warp呢？
这是因为有时候为了等待某些数据就绪，你不得不停下来。比如说，我们需要通过法线纹理贴图来计算法线光照，即使该法线纹理已经在 Cache 中了，访问该资源仍然会有所耗时，而如果它不在 Cache 中，那就更加耗时了。用专业术语讲就是 Memory Stall（内存延迟）。与其什么事情也不做，不如将当前的 Warp 换成其它已经准备就绪的 Warp 继续执行。

最后我们看下SM的变迁：

SMEvolution

可以发现从Fermi, Kepler到Maxwell，SM的计算核心core的数量一直在增加，这也就意味着算力的提升。但是我们也可以发现，实际上这三个产品并没有架构上的提升，享受的一直是摩尔定律的红利。
但是Turing架构就不一样了，它引入了tenser Core和RT core，带来了架构的较大变迁。

Nvidia TU102 GPU的规格

  • 4,608个CUDA Cores
  • 72个RT Cores
  • 576个Tensor Cores
  • 288个texture units
  • 12个32-bit GDDR6 memory controllers (384-bits total)

参考资料

http://simonschreibt.de/gat/renderhell/
https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline
NVIDIA-Turing-Architecture-Whitepaper.pdf

显示 Gitment 评论