分享

英特尔GEN9核显性能如何?

 金刚光 2020-05-29

HD Graphics 630核显性能如何?Intel Kaby Lake HD 630核显实测

今年初Intel正式发布了第7代Kaby Lake架构酷睿处理器,主要带来了桌面版产品。在性能测试方面,经过我们实测默频多线程提升8.88%,同频没有提升,被人诟病的挤牙膏现象依然存在。而Intel为Kaby Lake桌面版全系列标配了HD Graphics 630核显,最大区别就是不同型号之间的最大动态频率差异。

今天就让我们来测试这HD Graphics 630核显性能如何,能不能甩掉“牙膏厂”的恶名。

超能网特制Kaby Lake CPU核显规格一览表

在桌面级Kaby Lake架构处理器上我们再也见不到GT2级别以上的核显,全系标配GT2级别的HD Graphics 630。

Intel曾经花了大力气完成拥有128MB eDRAM的Iris Pro最强核显已经名存实亡,仅能在第七代移动版处理器上找到Iris Plus一些蛛丝马迹,那就是Iris Plus Graphics 640/650。

i7-6700K/7700K核心图

而根据之前的资料显示HD Graphics 630核显将GPU架构仍是基于上一代Skylake的第九代,属于GT2级别,拥有24个EU单元,重点增强了视频硬解码能力。

如此看来HD Graphics 630应该是HD Graphics 530的一个小升级,在架构上没有任何的大改动,我们可以称之为九代架构。

新的视频处理引擎

目前确切得知升级部分是Kaby Lake处理器使用了更强大的Multi-format Codec(MFX,多格式媒体编解码器硬件模块),支持10bit HEVC、8/10bit VP9视频格式的硬件解码,10bit HEVC、8bit VP9视频格式的硬件编码码;增加了intel无线高清显示技术支持,提高了AVC编码效率;对VQE引擎增加支持HDR和SDR,支持更Rec.2020更宽广的色域,使得输出视频画面色彩具可塑性。

此前的Skylake处理器gen9 GPU架构对不同视频格式编解码支持非常不错了,Kaby Lake处理器进一步加强了解码支持。

第6/7代Intel iGPU支持硬解码视频格式对比

第6/7代Intel iGPU支持硬解码视频格式对比

HD Graphics 630 VS HD Graphics 530 游戏性能测试:

虽然我们已经知道了Kaby Lake的iGPU架构与上代基本相同,我们仍然想知道两者之间的差距到底有多少。下面就让我们拿i7-6700K以及的i5-7600K的核显作为对比,看看性能提升幅度如何。

GPU-Z 1.16.0仍不能正确识别HD Graphics 630规格参数

i7-6700K的HD Graphics 530以及i5-7600K的HD Graphics 630默认频率都是350MHz,最大动态频率可以达到1.15GHz,因此可以很好的比较两者游戏性能,为了确保CPU性能不会对测试结果造成过大的影响,我们将i7-6700K和i5-7600K CPU主频固定在了4.2GHz上。

Intel ARK提供的HD Graphics 530/630规格对比

在3DMark Sky Drive以及Cloud Gate上,惊喜地发现HD Graphics 630对比HD Graphics 530有了差不多10%的性能提升,莫非是Intel藏着掖着什么没有公布的内部架构变化导致性能有所提升。但是接下来的3DMark Fire Strike以及游戏测试给了我们当头一棒。

HD Graphics 530/630 3DMark测试成绩性能比较

在游戏测试时,不知道是不是Intel官方驱动的问题,HD Graphics 630在游戏下找不到720P分辨率选项,只好用800P分辨率窗口模式代替测试。

HD Graphics 530/630游戏测试成绩比较

在3DMark Fire Strike以及游戏测试中,HD Graphics 630、HD Graphics 530两者之间性能表现可以说是完全一致的,最大不超过3%。换句话说HD Graphics 630是HD Graphics 530换汤不换药的产品,披个马甲再挤一挤。

HD Graphics 630核显什么设置下畅玩《守望先锋》?

IDF 2016上,Intel在演讲会上现场展示了Kaby Lake架构CPU核显能流畅玩《守望先锋》,那么全系标配的HD Graphics 630到底能在什么样的设置下畅玩例如《守望先锋》这样热门网络游戏呢?

IDF 2016上,Intel亲自用核显跑《守望先锋》,效果还蛮流畅

不同特效、不同分辨率下,HD Graphics 630跑《守望先锋》成绩

兼顾游戏画面分辨率以及画质、帧数的综合考量,如果你一定要在HD Graphics 630下玩《守望先锋》,那么小编建议你在1080P分辨率下,开启低特效以及100%渲染,此时画质损失不会太严重,同时帧数可以稳定在40帧左右,射击类游戏最注重游戏的流畅度。

HD Graphics 630在1080P分辨率下低特效玩《守望先锋》画质

HD Graphics 630 VS HD Graphics 530 视频解码测试:

既然Intel提到加强视频格式编解码的支持,只要免不了测试一番。特意挑选了3部格式、码率不一的视频进行测试,包括了上一代的H.264编码、最新的HEVC 10bit、以及新兴的VP9格式。

H.264/AVC是国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的数字视频压缩格式,目前网络广泛流传的视频基本采用此种编码,而且这个标准已经沿用了十多年,Intel早就对其进行了硬件支持,两代CPU均可对其进行硬件解码,减少CPU核心利用率,从而为移动平台降低功耗提供了基础。

测试视频是《jellyfish》,视频编码格式为H.264,分辨率为4K,码率高达250Mbps,使用Windows 10自带的Windows media player播放器播放。

H.264测试视频信息,本页图片都可以点击放大

可以看到视频播放时,i7-6700K以及i5-7600K的CPU占用了均在个位数,说明两者的iGPU硬件解码成功。

i7-6700K@HD Graphics 530播放时CPU占用率

i5-7600K@HD Graphics 630播放时CPU占用率

由于H.264标准实在是太老了,随着高清时代来临,视频的分辨率已经在不断提升,H.264已经不能很好对运动矢量进行预测及编码压缩率降低,同时数据冗余不断上升,以及没有针对高度并行化的CPU进行优化,制约了运算性能。因此2010年制定了全新的视频编码标准HEVC/H.265,相比H.264在同等画质下容量平均能减少50%,这样能让在网络之间的传播4K视频。

测试视频仍是《jellyfish》,视频编码格式为HEVC,色彩为10bit,分辨率为4K,使用Windows 10自带的Windows media player播放器播放。

HEVC 10bit格式测试视频信息

首先测试的是i7-6700K的HD Graphics 530核显,CPU的利用率已经飙升到72%,说明iGPU并不支持硬件解码,而是动用到CPU性能进行软件解码,而且此时画面非常卡顿,帧数只有个位数,毫不夸张地说观看感觉就比看PPT好一点。

i7-6700K@HD Graphics 530播放时CPU占用率

反观i5-7600K的HD Graphics 630播放的画面非常流畅,在4K屏幕下,水母的触须摆动看得一清二楚,水中的白色杂质也是清晰可见,CPU占用率仅为3%,确确实实支持HEVC视频格式的硬件解码。

i5-7600K@HD Graphics 630播放时CPU占用率

VP9是由Google主导开发的一个无使用授权费用、完全开放性的视频标准,而VP9应用场景主要是集中于浏览器的网络播放,而并非下载播放,目前Youtube已经率先全站采用该视频编码标准。

测试视频是《phfx》,视频编码格式为VP9,分辨率为4K,使用Windows 10自带的Windows media player播放器播放。

VP9格式测试视频信息

i7-6700K的HD Graphics 530核显表现与此前的HEVC一样,视频不能流程播放以及拖动播放,CPU占用率25%,播放器使用软件解码方案。

i7-6700K@HD Graphics 530播放时CPU占用率

而i5-7600K的HD Graphics 630则可以流畅播放,拖动视频会稍有卡顿但能继续正常播放,CPU占用率仅为4%,表明硬件解码成功。

i5-7600K@HD Graphics 630播放时CPU占用率

总结:

官方宣称第七代CPU支持VP9硬解码功耗下降7倍

三代iGPU视频编解码支持情况

总结:

通过对比i7-6700K的HD Graphics 530以及i5-7600K的HD Graphics 630性能测试,我们可以得知HD 630就是HD 530的“马甲”,对于游戏性能提升完全没有帮助。

但是对于一些视频党来说意义重大,因为HD Graphics 630架构升级在于对目前常见的视频格式编解码的完整支持,添加了HEVC 10bit、VP9硬件解码部分对于很多动漫爱好者来说可以说是福利。

至于核显战游戏,那么还是建议玩玩低画质、低特效的网络游戏,至于那些高大上的单机大作还是交给独显吧。

Intel Gen8/Gen9核芯显卡微架构详细剖析

一、兴趣问答

1、Intel核显的一个EU单元同频率下大约相当于A/N的几个流处理器单元?

答:大约是8个左右(因为EU单元内含有两个SMID-FPU单元,每个FPU单元四发射,理解为A/N的4个流处理器完全OK)

2、为啥上面说8个左右,而不是8个整?

因为I/A/N架构不一样,单精度浮点能力来衡量显卡的性能与比较最恰当不过,按单精度比值算的话,就是上面说的“左右”

3、单精度衡量I/A/N是否具有参考性?

有参考性,大体衡量核心的性能是OK的,但是显卡的性能除了受核心性能影响外也受显存带宽影响,I核显有专用显存的话显存容量也顶多128MB,借用内存的话,带宽要小于目前的主流的显存带宽,所以单精度差不多的话,I核显还要弱些

4、HD630性能怎么样,相当于今天的哪个独显的水平?

HD630约24个EU单元,频率从350-1150MHz左右主流HD630的最大睿频是1050MHz(我们就按1050MHz算),大体是1050MHz×24EU×2×(SIMD-FPU)4×(MUL+ADD)=403200MHz=393.75GFlop

  • GT1030实际游戏频率大约是1650MHz左右,单精度浮点约为:384×1650×2=1237.5GF,就是说GT1030的单精度浮点比HD630约高214%(加上显存上的性能优势性能会更高一些)

  • R7-240(现在300左右),单浮点约为:320×800×2=500GF,大约比HD630高14%

  • R7-350(现在400左右),单浮点约为:512×900×2=900GF,大约比HD630高128%

  • 老卡GT740,单浮点约为:384×993×2=744.75GF,大约比HD630高89%

由此来看,HD630的水平还不能与这些入门级独显相提并论,但说到实用性比如玩LOL在1080P开中等偏高特效还是能流畅玩的……

二、正文

为了让大家阅读第一手资料,又现去Intel官网查了链接,当然下面网友的解读也非常精彩

-----------------------------------------------

原文链接:【超冷知识普及】Intel Gen8/Gen9核芯显卡微架构详细剖析

作者:坎达拉克沙 写作时间:2015-10-23

自从Ivy Bridge架构以来,Intel在改进CPU计算性能方面似乎越来越“不思进取”。虽然制程和架构也一直按照tick-tock的步伐稳定前进,但给普通用户的直接印象就是单位频率的计算能力只有个位数百分比的提升。(农企:怪我咯)

Intel作为目前最大的显卡厂商(笑),其研制GPU的历史可追溯至上个世纪末,当时的810芯片组已经具备了板载集成的i704显示核心。接下来又有风靡一时的板载Graphics Media Accelerator显示核心,就是我们常见的GMA。从2010年的32nm制程Westmere架构的酷睿i系列处理器开始,GPU从主板被转移到了处理器package的内部,称作HD Graphics,中文一般称为核芯显卡,并沿用至今。

核芯显卡在早期就是性能孱弱的代名词,几乎是除了亮机之外,没有其他的用途。不过,核显的性能近年来可谓突飞猛进,到了Haswell时代,连低端赛扬都可以爽玩入门网游、硬解4K,高端的Iris系列核显甚至能碾压中低端独显。而Intel在GPU领域的华丽转身,只用了区区3年多的时间。

本文致力于解析目前的Intel Gen8 (Broadwell)核显与Gen9 (Skylake)核显的微架构(它们相同点很多),顺便也会简单讲一下Intel SoC的基本架构。另外,也会与前代核显作一定的对比,来探究其进步的原因。

编辑

这是一块四核心Intel Skylake处理器的组件分布图,大家可以把它想象成i5 6500、i7 6700K甚至i5 6300HQ。

图中四个蓝色框中就是计算核心,它们中间的绿色框代表共享的最后一级缓存(Last Level Cache, LLC)。深蓝色框中是负责与外界联系的“系统代理”模块,包含内存控制器、显示控制器、I/O控制器等。而最左边的红色虚线框内,就是核芯显卡,我们可以认为它是目前最常见的HD530。

由图中可以直观地看出,核显占整个芯片的面积还是比较大的,比例一般是35%~40%。

编辑

这是整个SoC的框图。首先来解释一下图中除了核显之外,大家比较生疏的三个要素。

1. 环状互联(Ring Interconnect)

这个设计是从Sandy Bridge微架构引入的,其本质是将CPU核心、LLC分片、代理模块、核显等组件联系在一起的环形拓扑总线。它可以双向传输,具有32字节(不是比特)的宽度,具有自己的时钟域(带有右下角小图标的组件就有自己的时钟域),带宽非常高。这种设计有利于芯片的模块化扩展,同时还可以加强存储资源的共享。

2. 最后一级缓存(Last Level Cache, LLC)

其实就是我们常说的三级缓存(L3 Cache),它是一个完全共享的、分布式的存储单元,位于CPU核心的外部(L1、L2缓存都在内部)。

每个CPU核心都可以得到一个相对固定的LLC分片,核显也可以利用它。它是系统访问内存前的最后一道关卡,由于访问缓存的速度要比访问内存快得太多,因此较大的LLC有利于减少延迟。目前,双核心的Intel处理器一般配备3~4M LLC,四核心的一般配备6~8M,甚至更多。

3. 嵌入式DRAM(eDRAM)

从上图右下角可以看出,系统代理模块中有一个可选的eDRAM控制器。所谓eDRAM,是位于整个SoC之外的一块快速记忆体,一般是64M~128M大,也有自己的时钟域。它有分别的总线用于读写,速度可高达32字节/时钟周期。它的作用与LLC基本相同,可以近似认为是L4缓存或者核显的内嵌显存,可以由CPU核心和核显共用,对提高核显的性能有重要的作用。当然,只有最顶级的型号才能拥有它。

大家可能已经看到上面的图中,已经把核显的结构也画出来了。下面我们就自底向上分析核显的微架构。

就像N卡有CUDA核心,A卡有流处理器一样,Intel核显在很小的芯片上,也设计了它自己的基本运算组件,它的名字叫执行单元(Execution Unit, EU)

编辑

上图就是一个EU的构成。从本质上来讲,它是一个细粒度多线程的、符合单指令多数据(SIMD)规范的处理模型。图中左侧绿色的部分是存储单元,它右侧的则是功能单元。

为了叙述简明,我下面用一行一条数据的方法来讲。

每个EU的存储单元中有7条线程,或者叫做通道;

每条线程上有128个通用寄存器;

每个寄存器可以存储具有8个元素的SIMD向量;

每个SIMD向量的元素长32bit。

这样,大家就可以理解图中的“28KB GRF”是怎么来的了,简单相乘即可。所谓GRF,就是通用寄存器文件(General Purpose Register File)。此外,每条线程还有一个用于保存线程状态的特殊寄存器组,它们叫做架构寄存器文件(Architecture Register File, ARF)。

EU经过取指令(Instruction Fetch)阶段之后,通过指令译码,与GRF中存储的数据配合,进行功能性的操作。

在每个时钟周期,EU最多可以并发执行四条指令,这四条指令必须来自于四条完全不同的线程。这些指令交由后面的线程枚举器(Thread Arbiter),再由枚举器分发给后面的功能单元之一进行处理。

由上图可以看到,功能单元也是有4个,分别是:发送单元(Send)、分支单元(Branch)、两个SIMD浮点运算单元(SIMD FPU)。

SIMD FPU是EU中起GPU计算功能的核心部件。虽然它们的名字叫做”浮点运算单元“,但它们既可以进行浮点运算,也可以进行整型运算。在一个周期中,每个FPU可以以SIMD的方式执行4个32bit运算,或8个16bit运算。在Gen9之前的核显架构中,都是不原生支持16bit运算的。

在FPU中,一次浮点运算是由一次加法和一次乘法组成,叫做乘加操作。因此,对于32位浮点运算而言,一个EU每周期可以执行(add + mul) x SIMD-4 x 2 FPU = 16次操作。

另外,具有分支效果的指令,如跳转、条件跳转、循环跳转的指令,则被枚举器发给分支单元处理。而那些需要较长延迟时间的操作(如访存),则被发给发送单元,再由它与外部组件联系进行下一步操作。

现在的GPU设计大多奉行模块化、可扩展的原则,也就是说,把一定数量的基本计算单元形成团簇,然后再由数量不等的团簇加上某些控制单元来构成整个GPU的运算组件。NVidia和AMD已经早早采用了这种方式。来举几个栗子。

N卡的计算单元团簇叫做流式多处理器(Stream Multiprocessor, SM),由一定量的CUDA核心组成。在Kepler架构中,192个核心组成一个SMX,而在Maxwell架构中,128个核心组成一个SMM。因此,我们常见的GT740M(GK107/GK208)就拥有2个SMX,而GTX960M(GM107)就拥有5个SMM。

A卡的计算单元团簇叫做计算单元(Compute Unit, CU),在GCN架构中提出,每个CU包含64个流处理器。例如,入门级的R5 M330(Oland)拥有5个CU,而中端偏高的R9 M375(Cape Verde)拥有10个CU。

Intel从Haswell时代的Gen7.5核显开始,也采用类似的设计思路。这是Intel核显性能开始跃进的关键点所在。它采用两级EU团簇结构设计,较低一级叫做子分片(subslice),较高一级叫做分片(slice)

编辑

这是Gen8/Gen9核显的子分片框图,可以明显地见到它包含8个EU,也就是说一个子分片包含56个线程/通道。图中有三个新东西,我们来一一看。

1. 本地线程调度器(Local Thread Dispatcher)

顾名思义,它用于向每个EU中的每个线程来分配任务。所有的指令先进入它内部的指令缓存,然后再由它来将这些指令分发给有空闲的EU,简单暴力。

2. 采样器(Sampler)

采样器是一个只读的访存单元,用于从其外部的存储单元中获取纹理或图像数据,并进行采样。除了采样之外,它还可以完成图像的坐标转换、过滤等。它内部也有分别的两级缓存,在L1和L2缓存之间,存在将压缩的纹理或图像解压缩的逻辑电路。

3. 数据口(Data Port)

它是专门管理数据存取的单元,负责与外部存储单元进行通用的数据交换。另外,它还可以进行SIMD操作的聚合,也就是将多个长度相同,并且偏移地址落在同一个地址段内的分散的SIMD操作放在一起处理,这样可以使带宽最大化,提高效率。

其实到了这里,大家可以看出核显(或者说所有具有计算功能的芯片)在架构上的精细性。每个单元都需要具有指令和数据的处理能力,并且需要保持与其高层或低层组件的信息交换。

编辑

将子分片集合在一起,然后再加上一些必要的组件,就变成分片了。绝大多数Gen9核显都是由3个子分片组成一个分片,也就是说包含24个EU。

由上图可以看出,各主要数据总线的读写速率都是64B/周期,这个值十分重要。为什么数据宽度是64B呢?

回忆一下,EU中的一个通用寄存器可以存储32B的数据,也就是SIMD-8x32bit。但在实际的运算过程中,有很多指令是SIMD-16的,这样的话就需要将一对通用寄存器视为一个SIMD-16寄存器,数据量就变成了64B。

这样,每个子切片的采样器和数据口在从切片的缓存(L3数据缓存)中读写数据时,宽度是64B。L3缓存中存储的数据,每条也是64B。L3缓存到整个SoC的LLC缓存的数据总线的宽度,当然也是64B了。这种统一性有利于各存储单元和运算单元间的协同工作。

切片的L3数据缓存(L3 Data Cache)是相对于各子切片的采样器缓存而言的,是高度bank化的存储结构,在Gen9架构中,它的大小是768KB。

每个子切片的数据口都要先从L3缓存中读取它们需要的数据,而采样器则先访问自身的L1、L2缓存,若找不到数据才要从L3缓存中读取。一旦出现缓存未命中的情况,L3缓存就要从LLC甚至系统内存中读取数据,再返回给子切片。由于带宽很大,总体来讲效率也是相当高的。

编辑

如上图所示,再把切片组合起来,加上必要的组件,就形成了核芯显卡的全貌。

Gen8核显可以由1个或2个切片组成,Gen9核显可以由1~3个切片组成。

具有1个切片(24个EU)的Gen8核显包括HD5300、HD5500、HD5600,2个切片(48EU)的Gen8核显则有HD6000、Iris 6100、Iris Pro 6200(带有128M eDRAM)。

Gen9核显的命名改成了三位数。具有1个切片的Gen9型号有HD515、HD520、HD530,具有2个切片的是Iris 540、Iris 550(带有64M eDRAM),具有3个切片的旗舰级型号就是Iris Pro 580(带有128M eDRAM)。图示的就是Iris 540/550,但eDRAM模块未示出。

当然,在这些分片的头上,还是多了两个控制组件的,一是命令流(Command Streamer),二是全局线程调度器(Global Thread Dispatcher)

命令流主要负责从核显驱动程序栈来接收底层的命令,并且将它们进行高效的组合和解释。至于全局线程调度器,它则是负责整个核显模块的负载均衡,统一管理所有子分片的本地线程调度器,并与它们协同工作。

上图中最下方的图形技术接口(Graphics Technology Interface, GTI),则是整个核显模块的大门,所有与SoC其余部分的交互都要穿过它,就像细胞膜之于细胞一样。另外,GTI还有负责一些原子性的LLC读写操作,以及最重要的电源管理功能。

按照Intel的说明,除去分片的其他组件,也就是命令流、全局线程调度器和GTI,它们所处的区域叫做”未分片“(unslice)区域。未分片区域区域处于一个特殊的、有很大自主性的时钟域中,通过它可以调节整个核显的性能表现。

编辑

这是架构剖析部分的最后一个话题,来看一下整个核显模块与SoC的存储结构。

大家应该早就知道了,核显的显存除了可能有的eDRAM之外,最主要的就是共享系统内存。Intel认为这种设计方式可以简化系统的复杂度,降低能耗,并且不需要添加额外的数据缓冲区。

近几代核显可利用的最大系统内存量都是1.7GB,但很少达到这个极端值。由于核显的GTI与内存之间只隔了一个LLC,因此我们可以认为系统内存的位宽和频率就是核显显存的位宽和频率,如上图右上角所示。

Haswell和Broadwell架构的处理器,最大可以支持到双通道DDR3 1866MHz(等效频率),但Intel官方声称为DDR3 1600MHz。每条通道的位宽为64bit(8B),因此在DDR3 1600MHz的条件下,核显显存的带宽就是25.6GB/s。

而Skylake架构的处理器全面支持DDR4,在DDR4 2133MHz的条件下,显存带宽达到了34.1GB/s,提升明显。

由图中也可以看到各时钟域对数据交换速率的影响。CPU核心与LLC交换数据时,其频率由环状互联的时钟决定;GTI与LLC交换数据时,其频率由核显核心频率决定;eDRAM和系统内存与LLC交换数据时,其频率由eDRAM或内存决定。

视频和视频帧:Intel GPU(核显)的编解码故事

写在前面

一般称基于“显卡或者多媒体处理芯片对视频进行解码”为硬解码,本文就将介绍如何用Intel的核显,即CPU上的集成GPU做硬解码。

QSV全称Quick Sync Video,是Intel在2011年在发布其著名的CPU制程Sandy Bridge的时候一起发布的,这是一项基于其核显进行多媒体处理,包括视频编解码的技术。题外话插一句:集成核显,官方称HD Graphics,其实最早是在Sandy Bridge上一代制程的时候就推出的硬件技术,不过,核显整体的性能得到充分发挥和提升是在Sandy Bridge的时候;于是,在下一代制程Haswell及以后发布了比HD Graphics更高端的Iris)。官方合称核显技术为HD/Iris Graphic,每代CPU的核显都在不断增强、内部结构也不断在调整,包括执行单元Execution Unit,EU)也在不断增加。前不久Intel对外宣称要做独立显卡了,之后其核显的发展具体如何就不得而知了。

在接手QSV项目的时候,原本以为QSV硬解应该有很多资料,实际上却相反,因此自己做个笔记记录下来。

本文将介绍:

  1. Intel核显的物理结构。包括CPU核心、最后一级缓存LLC,GPU的Slice和Un-Slice结构,以及编解码的MFF模块

  2. QSV技术。主要包括Intel的QSV底层库结构。

  3. 基于FFmpegQSV解码插件开发,以及用GPU做Memory-Mapping的优化

I. Intel的核显(集成GPU)

了解Intel的核显很有必要,说起来非常汗颜,笔者作为计算机专业出身,在几个月之前,笔者对CPU的认识还停留在上古的CPU“南北桥”架构上。所以,本章有任何不准确的地方,请指出,非常感谢!

首先看一张Gen11的CPU结构图(图片来自于Intel Processor Graphics Gen11 Architecture):

编辑

图1. Gen11 CPU架构图

首先来看CPU核心部分:上图1右边整块灰色部分。

  • 中间灰色上半部分是CPU Cores,也就是常说的CPU的物理核心:一块CPU上配置的计算单元个数,一般认为一块物理核心应该至少配备了L1(L2)缓存。在Linux操作系统上,CPU的物理核心总数也可以在/proc/cpuinfo里面通过指令cat /proc/cpuinfo查看的到;除此之外,还有CPU逻辑核心的概念,这是利用超线程技术模拟出来的核,一般来说,一个物理核可以虚拟出2个。相信大部分读者还听说过“大小核”:小核负责日常任务,大核则负责大型应用。这样设计的目的主要是为了节省功耗。不过,不管大小核还是多核,都有可能因为底层设计缺陷而出现“一核有难多核围观”的问题,不过这个问题是芯片工程师们该操心的事儿,上层开发们,少写点逻辑代码BUG已经是谢天谢地了。(逃)

  • 中间灰色下半部分是Shared LLC,英文全称Last Level Cache,也就是我们常说的最后一级缓存。有些芯片上是第三级缓存,有些则是第四级缓存,无论设计了多少级,最后一级缓存的作用都是一样的:物理核之间的数据交换。再多说几句,CPU上的缓存作用不用多说:弥补CPU和主存(也称内存,就是主板上的那几根内存条)的速度差太大,用于提高效率的。芯片工程师在底层会设计一系列算法增加缓存命中率以减小I/O的开销,当然物理核和缓存之间的布线和工艺,也是非常重要的。

  • 最右边细长的灰条部分承担整块芯片类似Agent的部分,包括显示控制部分、和外部做I/O部分的PCIe等。这里不多做赘述。

现在看CPU的核显,集成GPU部分。

首先,从上图1中可以看到:Intel的核显在整块CPU芯片中的占比是不小的,而且现在核显的算力不容小觑。想想在没有独立显卡的笔记本上,也是可以玩很多大型游戏,虽然偶有听人抱怨会卡、掉帧,但是整体的表现已经不错了。(逃,反正笔者不玩游戏)

接下来,看看官方给出的GPU内部的结构图:

  • Subslice:GPU的一个小型集成芯片。图1中可以很明显看到,它包括8块EU芯片,还有承担Dataport、Sampler、Thread Dispatch的芯片。

  • EU:GPU的执行单元,负责所有通用的计算功能

  • Dataport:承担Subslice和GPU其他部分的数据交换职责,官方说还会做“Memory request coalescence(内存请求合并)”,从其他资料上查到是聚合浮点数操作,即把浮点数放在一起处理,以提高整体带宽和处理效率

  • Sampler:有说法是做外部数据的纹理采样。【但是这个是干什么用的,笔者完全没理解,这里记一笔】;

  • Thread Dispatch:用于给每个EU中的每个线程来分配任务,即,所有的指令先进入它内部的指令缓存,然后再由它来将这些指令分发给有空闲的EU。

编辑

图2. Gen11 GPU架构放大图

GPU内部其实远比上图复杂,上文提到的也只是GPU Slice部分的Subslice芯片的结构,Slice部分还有:

  • L3 Cache:负责Subslice之间的数据通信,作用和CPU核心上的LLC作用类似,只不过,LLC负责的是CPU Core之间的数据通信。

  • Slice Common:官方说法是“能够支持2个甚至更多的subslice芯片工作的,可扩展的ff assets”,看上去似乎也是Subslice的辅助功能,官方解释的原文如下:【笔者没有深究,留个坑吧】
    Scalable fixed function assets which support the compute horsepower provided two or more subslices.

GPU可以分为Slice部分和Un-Slice部分。上文已经介绍完整个Slice部分,接下来介绍Un-Slice部分,对应图2最上方部分。

  • GTI:全称Graphics Technology Interface负责GPU和CPU内存部分的数据通信(笔者认为,这里应该还包括指令数据),官方说法如下:
    the gateway between GPU and the rest of the SoC. The rest of the SoC includes memory hierarchy elements such as the shared LLC memory and system DRAM
    (GTI)是GPU与其他SoC之间的“网关”。 SoC的其余部分包括内存各层元素,例如LLC和系统DRAM

  • MFFMedia Fixed Function,这个模块一直没有找到明确的官方说法,在文档中还提到了MFX/VQE/SFC,笔者查阅了很多资料,整理如下:

  • MFX:全称Multi-format Codec,即多媒体解码器,在intel官方文档Programmer's Reference Manual中称为“Video Decode (VD) Box”,但是这个名称在外部搜索的时候资料远少于MFX,而且在很多流出来的PPT资料中看到的多是MFX模块。但是,无论名称如何,这是负责多媒体编解码的独立模块,并且intel的QSV硬解,就是在这个模块上进行解码的

  • VQE:全称Visual Quality Enhancement,从名称来看是做视频增强的真进步还是挤牙膏?Intel七代酷睿最全解析的说法是:该模块能够以较低的能耗做色彩增强、矫正等。笔者的理解是,除了编解码之外的大部分多媒体处理工作,都是该模块负责的

  • SFC:全称Scaler and Format Conversion,这个模块的介绍资料就更少了,是负责视频scale和format conversion(格式转化,如NV12转NV21)原文是transcode(转码),这个地方描述不正确。

笔者在网上找到了一张图,见下图3。图中所示是在MFF上进行视频处理的整个流程:1). 首先在MFX/VDBOX模块上进行编解码; 2). 接着送到VQE/VEBOX上做图像增强和矫正处理; 3). 然后送到SFC上做scale和transcode;4).最后送出到显示屏上展示。【至于真实是否如此,笔者在这里记一笔。】

编辑

图3. MFF流程图

笔者推荐知乎文章【转】Intel Gen8/Gen9核芯显卡微架构详细剖析,介绍的是第9代CPU结构的,文章深入浅出,上文关于thread dispatch的说明就是出自这篇文章。

最后,用网上找到的一张图(当时忘记记录来源了,侵删)总结Intel集成GPU/核显的结构:

编辑

图4. GPU流程架构图

  • 中间部分写着“EU”的整块非常明显是Subslice,如上文介绍的,包括Dataport和Sampler,承担了整个GPU的绝大部分计算职责;

  • Subslice上方紫色部分就是MFF,包括了MFX\VQE\SFC,承担了多媒体处理的职责。

  • Subslice右边的蓝色等腰梯形是Thread Dispatch,分派具体的执行任务给具体EU芯片。

  • Thread Dispatch右边蓝色矩形块应该就是GTI模块,从CPU中载入数据,最后把处理完毕的数据载出。

注意,这个是skylake架构的GT2/GT3/GT4的GPU结构图,GTXX数字越大,集成的SliceUnslice芯片更多,能力越强,必然价格也更高。

II. Quick Sync Video(QSV)技术

QSV是Intel推出的将视频处理送到其GPU上专门负责视频处理的硬件模块处理的软件技术,维基百科上有一段话描述如下:

Unlike video encoding on a CPU or a general-purpose GPU, Quick Sync is a dedicated hardware core on the processor die. This allows for much more power efficient video processing
与CPU或通用GPU上的视频编码不同,Quick Sync是处理器芯片上的专用硬件核心。 这使得视频处理更加强大有效。

通过第一章的学习,笔者认为“dedicated hardware core”应该就是MFF模块组。要了解QSV如何驱动GPU的MFF,首先上一幅来自Intel官方Intel® Video and Audio for Linux上的图:

编辑

图5. QSV-FFmpeg架构图

在介绍QSV之前,插一句题外话,Intel在FFmpeg上提供的插件除了ffmpeg-qsv之外,其他还有ffmpeg-vaapiffmpeg-ocl,官方介绍如下(本文只介绍QSV,其他两类读者可以自行了解):

·

FFmpeg-vaapi

is an FFmpeg plugin, which supplies hardware acceleration based on the low-level VAAPI interface that takes advantage of the industry standard VA API to execute high-performance video codec, video processing, and transcoding capability on Intel GPU.

·

FFmpeg-qsv

is an FFmpeg plugin, which supplies hardware acceleration based on Intel GPU. It provides high-performance video codec, video processing, and transcoding capability based on Intel

Media SDK

library.

· FFmpeg-ocl is an FFmpeg plugin, which supplies hardware acceleration based on industrial standard OpenCL on CPU/GPU. It is mainly used to accelerate video processing filters.

· FFmpeg-vaapi是一个FFmpeg插件,它提供基于低级VAAPI接口的硬件加速,利用行业标准VAAPI在英特尔GPU上执行高性能视频编解码器,视频处理和转码功能。
· FFmpeg-qsv是一个FFmpeg插件,提供基于Intel GPU的硬件加速。 它提供基于Intel Media SDK库的高性能视频编解码器,视频处理和转码功能。
·FFmpeg-ocl是一个FFmpeg插件,它在CPU/GPU上提供基于工业标准OpenCL的硬件加速。 它主要用于加速视频处理过滤器。

言归正传,QSV插件在ffmpeg2.8及以上的版本就支持了,这个说法来自官方白皮书Intel Quick Sync Video and FFmpeg Installation and Validation Guide。上图5可以看到:QSV插件到底层需要经过MSDK、LibVA、UMD和LibDRM,那就一层一层来分析。

· MSDK

MSDK的全称是Media Software Development Kit,是Intel的媒体开发库,它支持多种图形平台(graphics platforms),实现了通用功能,能对数字视频进行预处理、编解码、以及不同编码格式的转换。该工具的源码地址在Intel® Media SDK,可以在Linux平台上编译使用。

· VA-API

VA-API全称Video Acceleration API在用户态暴露可以操作核显的API,这是一套类unix平台提供视频硬件加速的开源库和标准,并不是Intel独有,NVIDIA和AMD都有对应的API工具。Intel的源码地址在Intel-vaapi-driver Project,可以在Linux平台上使用,知乎的问题FFmpeg为什么迟迟不启用vaapi解码/编码?的高赞回答可以帮助快速了解VA-API。

· UMD

首先吐槽下Intel的官方的英文缩写实在太多了,而且好多缩写在Google上很难搜到相关的内容,UMD就是个例子。好在官网上解释了:UMD是User Mode Driver的缩写,在这里指的其实是VA-API Driver。而Intel提供了2个工具: intel-vaapi-driver 和 intel-media-driver,前者是历史遗留的,后者是新提供的。推荐使用后者。

· LibDRM

DRM全称是Direct Rendering Manager,即直接渲染管理器,它是为了解决多个程序对 Video Card资源的协同使用问题而产生的。它向用户空间提供了一组 API,用以访问操纵 GPU。该段话引用自Linux 下的 DRM,从Intel官网中还可以知道,DRM还是一套跨多驱动管理的中间件,承接用户态的VA-API和内核态的各类driver。同VA-API,DRM也是一套Linux/Unix平台上通用的解决方案。

· Linux Kernel

Intel的kernel是i915 driver,历史上还有i810,笔者没有研究过这一块,只放一张libDRM和Kernel Driver之间的关系:

编辑

图6. libDRM和Kernel Driver关系图

由此,至上而下的调用层级关系已经结束,至于内核态的驱动如何将用户态的指令转化为底层驱动的指令,笔者肯定是不知道的(逃),但是到这里整个关系图应该比较清晰了。

III. FFMPEG+QSV解码

QSV硬解要做的事总结起来无外乎以下几件事:

  1. 在解码初始化时打开底层驱动

  2. 解码之前指定解码器codec为h264_qsv

  3. 解码时把h264流数据送到GPU的解码模块上解码;

  4. 继续在GPU上执行后续操作 或者 送回CPU/内存;

至于3-4步操作,比如怎么样把h264视频流送到MFF模块上、如何调用MFF模块完成解码工作,最后如何把数据送回CPU/内存,底层库会帮助完成。不过,想称为一个优秀的工程师,之后还是应该花时间认真研究下FFMPEG源码的。【记一笔,还需要继续深入学习】

接下来介绍如何在使用FFmpeg API中的h264_qsv解码器插件

插一句题外话,FFmpeg的命令行使用办法推荐阅读官方资料QuickSync或者Intel_FFmpeg_plugins,前者还介绍了每一代Intel CPU产品增加了哪些codec(H264解码器很早就支持,H265直到skylake才完全支持):

编辑

图7. 每代CPU的硬件支持表

关于sample code,笔者踩过很多坑,总结一句话:大多数中文博客太不可信,还是要相信官方demo。然而官方的demo挺多的,笔者亲身实践来说,肯定有2份官方代码可用:qsvdec.chw_decode.c。笔者最早用的时第一段代码,硬解相关的核心部分如下:

/* open the hardware device - 打开硬件!!!必须放在前面完成 */ ret = av_hwdevice_ctx_create(&decode.hw_device_ref, AV_HWDEVICE_TYPE_QSV, "auto", NULL, 0); if (ret < 0) { fprintf(stderr, "Cannot open the hardware device\n"); goto finish; }  /* initialize the decoder - 注册使用h264_qsv codec */ decoder = avcodec_find_decoder_by_name("h264_qsv"); if (!decoder) { fprintf(stderr, "The QSV decoder is not present in libavcodec\n"); goto finish; } // 常规操作 - 复制codec decoder_ctx = avcodec_alloc_context3(decoder); if (!decoder_ctx) { ret = AVERROR(ENOMEM); goto finish; } // 硬解相关代码 decoder_ctx->codec_id = AV_CODEC_ID_H264; if (video_st->codecpar->extradata_size) { decoder_ctx->extradata = av_mallocz(video_st->codecpar->extradata_size + AV_INPUT_BUFFER_PADDING_SIZE); if (!decoder_ctx->extradata) { ret = AVERROR(ENOMEM); goto finish; } memcpy(decoder_ctx->extradata, video_st->codecpar->extradata, video_st->codecpar->extradata_size); decoder_ctx->extradata_size = video_st->codecpar->extradata_size; }  decoder_ctx->opaque = &decode; decoder_ctx->get_format = get_format;

可是,这份代码有个问题,笔者测试发现在同样的环境(赛扬系列的一款CPU)上,MSDK在1080p视频上可以达到500fps,这意味着h264_qsv在这个平台上理论上限也应该是500fps数值,但是实际这段代码测试下来连50fps还不到。排查下来发现是av_hwframe_transfer_data()的性能较弱。

最终和Intel一起解决了这个性能问题。

那么,一定有读者好奇,究竟是采取了什么方案进行了性能提升呢?

答案:采取了GPU-COPY技术做Memory-Mapping。

要解释这个问题,需要先了解GPU和CPU是怎么渲染图像的,这是一个非常复杂的过程,包括坐标系转化、纹理叠加等一系列过程。这里只需要了解2点:

  • CPU组织数据的方式是linear(线性模式)

  • GPU组织数据的方式是tile(图块模式)

后者的数据组织方式可以更充分地利用GPU的并行特点,加速图像处理、渲染。虽然目前tile存在一些纹理叠加的技术难题,不过从就其带来性能上的提升来说,牺牲一点效果就显得微乎其微了。这大概也解释了为什么说硬解效率高,但是精度效果上有所损失

接下来,解释下什么是Memory-Mapping:从Intel的CPU架构图上可以看到,GPU和CPU是放在同一块芯片上的,各自的寄存器/缓存区容量有限,因此视频数据主要还是存储在内存上。因为GPU和CPU组织数据的方式的差异,因此即便同一帧数据存放在内存条上同一个地方,数据存储格式是不同的,所以需要做Memory-Mapping。一般来说,Memory-Mapping相较于Memory-Copy,减少了数据从内存条上的区域A搬移到区域B的操作,已经是一个很不错的优化了。不过,这里还可以进一步优化:由GPU来完成Memory-Mapping以及数据从GPU到内存和CPU的操作原文只说了Memory-Mapping,这就是所谓的GPU-COPY技术。

av_hwframe_transfer_data()内部,Memory-Mapping的操作是由CPU完成的,因此性能卡在CPU上,只能并行完成。修改后,整体性能由不到50fps提升到300fps,虽然和理想的500fps还有一定差距,但足已我们的性能需求了。

据悉,Intel将在FFmpeg 4.3开源出这个解决方案。

写在后面

我想肯定有读者想问:了解GPU底层有什么(实质性)帮助吗?说老实话,作为应用开发人员,还真的没啥帮助。因为就算了解了芯片布线的重新设计、制程工艺提升使得同样面积的芯片能够容纳更多的晶体管、GPU-COPY技术在数据I/O上带来的提升(部分应用场景)......我们也不能做什么,说到底,芯片架构是芯片工程师的事儿,底层逻辑实现是嵌入式工程师的事儿。应用开发人员还真帮不上什么,不过作为知识库扩充,或者就当茶歇饭后读物,了解了解也未尝不可。

希望有机会可以接触CUDA的编解码,进一步学习N卡的精妙设计。

最后,非常荣幸因为《视频和帧》系列文章结识了不少朋友,并且非常热心帮忙指正文章描述不正确的地方。

文章中有不严谨的地方,欢迎指摘。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多