下载掌阅APP，畅读海量书库
立即打开
前面已经介绍了英特尔GPU的整体架构，本节重点介绍相对独立的视频固定功能单元模块MediaFF（FixedFunction）。因为是固定功能硬件模块，所以从公开的资料上很难看到其内部的硬件布局，请大家理解。图2-2来自英特尔发布的视频处理指导手册（Intel_Media_Developers_Guide.pdf），可以让大家形成一个比较直观的概念。
图2-2 视频引擎架构
视频引擎是独立于执行单元的固定功能模块，同时显示里面包含两个逻辑单元，一个是VDBox/MFX，另一个是VEBox/VQE。VDBox表示视频解码模块（Video Decode Box），也许因为早期的视频加速处理只局限于解码，所以当时就取了这个名字，一直沿用至今，但是编码也同样是在VDBox里面执行的；VEBox表示视频像素处理模块（Video Enhancing Box），是用来进行视频图像处理的，例如进行颜色空间转换、缩放等操作，与编解码就没什么关系了。因为VEBox用了字母E，使得很多视频处理的开发者理所当然地认为VDBox是做解码的，VEBox是做编码的，其实并不是，再强调一下，VDBox包含编码和解码的所有操作，而VEBox是用来做视频图像处理的，当然命名给大家造成了误会，也请大家谅解。
另外，VDBox和VEBox是目前较常使用的描述具体功能模块的名词，而与它们相关的名字则更多的是从逻辑功能模块的角度来表述的。MFX表示多格式编解码（Multi-Format Codec）引擎，包括多格式解码（Multi-Format Decoding，MFD）模块和多格式编码（Multi-Format enCoding，MFC）模块。而VQE则表示视频质量引擎（Video Quality Engine），尽管VQE也许会更直观地表示本引擎工作的主要领域，但是VEBox更加常用，VQE目前已经慢慢淡出历史舞台。相反，有些技术文档还在使用MFX来描述编解码引擎。但是在本书中，我们后续会使用VDBox和VEBox来描述视频引擎中的编解码模块和视频图像处理模块。
当然，使用了固定管线功能模块并不意味着会用到EU，某些灵活多变的算法，例如运动估计、帧内预测以及码率控制等功能的计算，甚至是客户自己设计的算法，都会用到EU，从图2-3所示的视频引擎早期逻辑处理管线中可以看到，早期的很多模块仍然是运行在EU上的，即使当前的编码实现也有部分是需要运行在EU上的。从图2-3可以看到，英特尔的视频引擎主要有两个相对独立的逻辑功能模块，一个编码模块ENC里用到的主要硬件单元是EU，另一个是固定功能模块PAK，里面的各个功能模块都已经固化，是完全采用硬件执行的管线，效率和能耗方面都比编码模块好很多，只是灵活性和扩展性不够。这也是英特尔视频引擎能够同时兼顾高效的编解码需求，也能兼容一些新格式需求的原因，对于一些成熟的视频编码标准，例如MPEG-2的视频部分、H.264/AVC等标准，就可以使用固定管线来做，而对于一些较新的标准，例如H.265/HEVC、AV1等，就可以通过编码模块先用EU进行计算，然后慢慢转到使用固定管线来计算。这样，随着GPU功能和性能的发展，越来越多的功能会从EU转到使用固定管线来运行，这样用户就能够拥有更好的产品体验了。
图2-3 视频引擎早期逻辑处理管线
为了减少对EU的占用，进一步提高编解码的性能，从Gen9开始，英特尔增加了一个专门的固定功能编码引擎，称作VDENC，它就是专门用来做编码的硬件管线，从命名上可以理解为VDBox中专门用来做编码（encode）的模块，即VDBox-Encode。VDENC不依赖于EU和VME进行运动估计和模式决策。这节省了带宽和功率，并提供一个独立的编码管线，可以更好地管理服务质量特性，主要用途是进行低功耗视频会议和视频捕获。
正是因为英特尔的视频引擎有了两种实现架构，所以从软件开发的角度看，英特尔的GPU会提供两种视频加速处理的模式：QSV-PG（Quick Sync Video Processor Graphic）模式和QSV-FF（Quick Sync Video Fixed Function）模式。它们的主要差异在于运动估计、编码模式选择，以及码率控制任务是哪个模块完成的。在QSV-FF模式下，运动估计和编码模式选择是固定功能模块（Fixed Function，FF）来完成的，但是码率控制任务则是由硬件模块HuC来完成的。在QSV-PG模式下，ENC阶段是在EU里面执行的，在QSV-FF模式下，ENC阶段是在VDENC里面执行的。所以，QSV-FF模式相对于QSV-PG模式具有低延迟、低功耗的特点，典型的使用场景包括无线显示、截屏、摄像头采集、视频会议等。另外，其总体设计编码吞吐量也许不如PG模式。H.264/AVC是从Gen9开始支持QSV-FF模式编码的，而H.265/HEVC则主要是从Gen11开始支持的。
随着H.264/AVC取得巨大成功，越来越多的焦点开始汇聚到H.265/HEVC上面，顺应潮流，英特尔的GPU中也加入了高效视频编解码管道（HEVC/VP9 Codec Pipeline，HCP），它是一种具有固定功能的硬件视频编解码管道，负责对HEVC流进行编码和解码，目标分辨率为8K（7680×4320像素），每秒30帧。HCP的硬件管道设计支持两种编解码器标准——HEVC和VP9。它实现了完整的解码过程，而且HEVC和VP9的解码器都完全符合标准。HEVC/VP9编码器体系结构主要由两个硬件组件组成：VDENC和PAK。此外，HEVC架构还支持通用执行单元+运动估计模块（Video Motion Estimation，VME）的组件模式，同时它还支持多编码通道模式来提升编码效率。需要强调的一点是，每个HCP编解码器的命令序列都是基于帧的。
除了VDBox模块以及VEBox模块，为了加强低功耗显示的需求，从Gen9开始，又一个专用的支持多格式的图像缩放和图像格式转换的硬件管线模块（Scaler & Format Converter，SFC），被引入GPU的大家庭中。几种节能技术也被加入SFC的架构中：把负载从EU转移到固定功能单元模块以降低SoC的动态功耗，减少内存之间的通信来降低IO和DDR的功耗，以及支持加速引擎之间的原生帧缓存。对于SFC，有两种基本的应用场景，如图2-4所示。
图2-4 SFC在视频处理显示管线中的应用
作为一个功能固定的硬件加速模块，SFC模块必须直接连接在VDBox或VEBox模块的后面，从而可以与它们并行运行，这样可以减少对EU的使用，例如，解码和缩放将同时执行，或者图像增强和缩放将同时执行。这种设计通过将视频图像处理的缩放操作负载转移到功耗更小的专用模块SFC来运行，从而达到高效省电的目的。
在这两种使用场景中，SFC模块的数据由解码器（VDBox）或图像增强器（VEBox）直接送入，而不是由它们把数据写入存储器后再从存储器读回来。在VDBox到SFC以及VEBox到SFC之间各自增加了一条直接数据总线。SFC模块还包括一个内部存储缓冲区，用于获得列/行之间的重叠像素数据。所有操作都在GPU内部处理，等都处理完之后，才通过IO接口把数据写回内存中，这样就减少了与外部的数据交换，提高了效率。
不管是跟VDBox相连还是跟VEBox相连，在这两种情况下，缩放操作都是把图像像素数据发送给显示引擎（display engine）之前的最后一个处理步骤，而且SFC还被设计用于生成显示引擎所需要的原生的图像格式，这就消除了因为不同引擎处理的图像格式的不同而造成的额外的内存复制操作，从而减少了对内存的操作。此外，SFC还支持图像沿顺时针90°旋转，非常适合用于移动平板的设计。
由上面的描述可知，SFC管道是一种共享资源，通过与VDBox/VEBox直接相连，并由VDBox或VEBox控制参数，而图像像素数据则直接发送给SFC模块进行调用和访问，这有助于通过消除到内存的通信量来降低IO通信消耗，并允许VDBox/VEBox与SFC管道并行运行。
通过前面的介绍我们知道，对于视频处理应用，英特尔GPU有理想的特性组合。
硬件加速编解码功能支持多个主流标准，例如AVC、HEVC、VP9等。
这些编解码器可以直接访问硬件的加速模块，即使是运动估计部分，也可以用硬件模块来加速客户的算法。
硬件加速模块可以加速很多常用的图像处理算法。
可以创建客户自己的管道，把客户自己的算法和系统提供的模块进行融合。
高端GPU提供大于1TFlops的算力来提升用户自定义模块、计算机视觉的效果，改进编码质量等。
编解码器的操作，需要使用CPU、EU、GPU共同完成。
低功耗，高运算密度，低综合成本。