JPEG 在 GPU 上压缩性能瓶颈分析
原创
目前市面主流用于服务器进行计算的Tesla系列GPU，主要有K80，P4，P40，P100，M40，这些卡性能指标有着不同差异导致成本上也相差很多。
鉴于AI是当下最火的技术方向，GPU加速运算在这方面又有天然的优势，所以官方在介绍其性能差异时主要针对AI各个计算框架来展示其加速比。
而针对于图像压缩处理这样的场景来说，其计算量较AI又有着很大的差异。为此有必要针对于图像压缩处理这样的场景进行性能分析。
图像压缩流程
首先来看我们的应用的计算过程，部分代码在CPU上运行，部分代码在GPU上运行。在CPU和GPU上的数据需要通过PCIE在主存和显存之间进行交换。
数据交换阶段
以三通道的JPEG图像resize为例，从读取图片数据，解码数据，resize图像，编码图像，拼接图像的完整时序如下图所示：
进入GPU的第一步是图像huffman解码后的数据拷贝到显存，而拷贝是通过PCIE Bus来进行的。那么PCIE bus的bandwidth以及多卡时的物理拓扑就将决定数据拷贝延迟。
就目前我们配置的M40标准设备而言，GPU不直接与CPU相连，而是每两卡挂在pcie switch上，pcie switch再连接到CPU，”PLX Technology, Inc. PEX 8747 48-Lane, 5-Port PCI Express Gen 3 (8.0 GT/s)”
每个PEX 8747共五个端口，其中一个x16端口是和CPU做连接，剩下的四个端口用于连接GPU，我们拿到的设备每两卡挂一个switch，每卡的lane width为x16，理论传输带宽为16GB/s。 当配置4卡时，每卡的lane width为x8，理论传输带宽为8GB/s。switch与cpu之间的lane width为x16。
那么如果同时两卡或四卡有数据在CPU与GPU之间进行传输时。那么16GB/s的带宽将被共享。鉴于图片压缩这样的应用场景各个GPU之间无数据共享的需求，那么无需配置PCIE switch。
而采样GPU直连CPU这样的拓扑结构每张GPU能独占16GB/s的pcie传输带宽。M40/P4 实际测试单卡传输带宽双向12GB/s。而多卡共同传输时P4带宽下降不显著。
M40标准设备物理拓扑:
GPU0 GPU1 GPU2 GPU3 GPU4 GPU5 GPU6 GPU7 CPU Affinity
GPU0 X PIX PHB PHB SOC SOC SOC SOC 0-13,28-41
GPU1 PIX X PHB PHB SOC SOC SOC SOC 0-13,28-41
GPU2 PHB PHB X PIX SOC SOC SOC SOC 0-13,28-41
GPU3 PHB PHB PIX X SOC SOC SOC SOC 0-13,28-41
GPU4 SOC SOC SOC SOC X PIX PHB PHB 14-27,42-55
GPU5 SOC SOC SOC SOC PIX X PHB PHB 14-27,42-55
GPU6 SOC SOC SOC SOC PHB PHB X PIX 14-27,42-55
GPU7 SOC SOC SOC SOC PHB PHB PIX X 14-27,42-55
Legend:
X = Self
SOC = Connection traversing PCIe as well as the SMP link between CPU sockets(e.g. QPI)
PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
PXB = Connection traversing multiple PCIe switches (without traversing the PCIe Host Bridge)
PIX = Connection traversing a single PCIe switch
NV# = Connection traversing a bonded set of # NVLinks
P4设备物理拓扑:
GPU0 GPU1 CPU Affinity
GPU0 X PHB 0-11,24-35
GPU1 PHB X 0-11,24-35
Legend:
X = Self
SOC = Connection traversing PCIe as well as the SMP link between CPU sockets(e.g. QPI)
PHB = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
PXB = Connection traversing multiple PCIe switches (without traversing the PCIe Host Bridge)
PIX = Connection traversing a single PCIe switch
NV# = Connection traversing a bonded set of # NVLinks
当在上述两者物理拓扑上进行图像压缩时，得到如下数据拷贝延迟数据ms(传递36MB的数据：分辨率单通道huffman解码后字宽采样因子，4032x3024x2x（1+0.25+0.25）)：
设备类型 | 单卡线程数目 | 使用GPU卡数 | 时延 |
|---|---|---|---|
M40 | 1 | 1 | 3.023 |
M40 | 1 | 8 | 6.019 |
P4 | 1 | 1 | 2.955 |
P4 | 1 | 2 | 3.261 |
从上述实测延时上，也反映了M40这样的物理拓扑存在的带宽竞争问题。
数据计算阶段性能
不同型号的GPU其计算能力间存在一定的差异，性能指标上也有所不同。以下是nvidia给出的各卡之间浮点运算能力，显存大小，显存带宽，与CPU的连接方式，ECC，以及功耗做了对比。
而图像编解码压缩过程中对浮点运算性能要求不高，速度快慢与GPU的core数量有较大关系。在缩放阶段需要目标像素宽x高的gpu线程来处理目标像素的生成。
各卡的GPU core数目:
GPU | K80 | M40 | M4 | P4 | P40 |
|---|---|---|---|---|---|
cores | 4992 | 3072 | 1024 | 2560 | 3840 |
相对于机器学习的计算量，图像处理计算量就显得很少。上述GPU物理核心数量虽然各不相同相较于少量计算而言，虽然处理耗时上存在差异，但就图像压缩处理场景而言，并不构成主要矛盾。
以下是在M40和P4上实测得计算过程消耗时延ms:
GPU | 单卡线程数目 | 使用的GPU卡数目 | IDCT | resize | DCT | huffman含api延时 |
|---|---|---|---|---|---|---|
M40 | 1 | 1 | 2.987 | 1.269 | 1.923 | 1.514 |
M40 | 1 | 8 | 2.985 | 1.257 | 1.922 | 26.72 |
P4 | 1 | 1 | 1.599 | 1.596 | 1.038 | 1.919 |
P4 | 1 | 2 | 1.598 | 1.577 | 1.037 | 1.93 |
由上述实测时延与GPU使用率分析，图像处理再GPU上的消耗相对较少不构成图像压缩处理的主要矛盾,那么对GPU的core 数目与浮点能力的要求就低很多。
测试过程中同样发现当单卡上的线程数目增加时,在kernel上运行的核函数增长会导致GPU上的kernel launch时间变长, 同时随着运行的卡的数目的增加，显存上内存分配释放的runtime api时延会呈现数量级的增长。经过与nvidia的同学交流，该问题主要与运行的卡数量和卡自身显存的大小有关系。
P4单卡单线程处理过程
单卡单线程，数据拷贝没有竞争，核函数执行阶段没有延迟，数据准备好之后就开始进行计算。
P4双卡每卡四线程处理过程
每卡四线程处理流之间对pcie形成竞争，launch核函数上也存在一定的延迟。
M40八卡每卡单线程处理过程
单机上运行的GPU卡越多,内存分配释放的runtime api层面的调用延时就增长的越迅速，成数量级增加远远的超过了正常计算时延。
整体影响因素和性能结论
通过上述分析，针对图片压缩处理这样计算量相对较小，数据拷贝频繁的应用场景，尽可能的减少pcie bus上的传输带宽的竞争。适当控制每卡上运行的处理流，单机配置少量的GPU卡， 尽可能的将动态分配的内存静态化，这样有利于在GPU利用率和处理时延上取得平衡。因为数据传输延迟远远大于实际计算延迟，所以我们倾向于将pcie bus的带宽跑满作为最大的处理量。 其次GPU的物理设备不需要最好的，普通的Tesla 系列GPU的计算性能已经能满足该场景下的计算加速,在物理拓扑上最好采用GPU直连CPU的模式与物理CPU均匀分配连接。
利用当前的M40架构，在GPU加速所取得的现网时延ms(编解码部分没放到GPU上进行)
分辨率 | GPU | CPU | docker |
|---|---|---|---|
>2000x2000 | 143 | 366 | 393 |
2000x2000~1500x1500 | 55 | 145 | 175 |
1500x1500~1000x1000 | 37 | 98 | 114 |
1000x1000~500x500 | 28 | 57 | 74 |
500x500~200x200 | 16 | 24 | 47 |
200x200~100x100 | 8 | 10 | 13 |
当图像分辨率超过500x500之后，使用GPU进行图像压缩相对于纯CPU时延降低了50%以上。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。