Google VP9 优化

Intel 平台上的 Android

0/5 (0投票)

2016年4月15日

CPOL

7分钟阅读

19740

2015年初，英特尔汇集了一支在性能优化方面拥有深厚背景的资深工程师团队，旨在优化VP9视频编解码器，以在Intel® Atom™平台上获得更高的性能。

Intel® Developer Zone 提供跨平台应用程序开发工具和指南、平台和技术信息、代码示例以及同行专家的经验，帮助开发者创新并取得成功。加入我们的社区，了解Android、物联网、Intel® RealSense™技术和Windows，下载工具、获取开发套件、与志同道合的开发者交流想法，并参与黑客松、竞赛、路演和本地活动。

引言

我们都曾有过观看电影或音乐视频，却在最精彩的部分卡顿或缓冲而感到沮丧的经历。YouTube*、Netflix*和Amazon*等平台一直在努力为客户提供最高质量、最快速的流媒体播放。为此，2015年初，英特尔汇集了一支在性能优化方面拥有深厚背景的资深工程师团队，旨在优化VP9视频编解码器，以在Intel® Atom™平台上获得更高的性能。

什么是VP9？

它是由Google开发的免版税的开源视频格式。与需要许可的高效视频编码（HEVC）相比，它具有优势。
它用于YouTube*、其他视频服务和部分智能电视上的4K分辨率内容。
它支持Chrome*、Chromium*、Firefox*和Opera*中的HTML5播放。

它是如何工作的？

VP9使用不同大小的像素块来编码和解码视频内容。它利用复杂的算法，系统地将原始数据紧凑地压缩，以便通过互联网流进行广播。具体来说，VP9可以在64x64到4x4的组合块大小上运行，以实现不同细节级别，这使得它能够高效地重现从开阔的蓝天到您所爱之人面部细节的各种内容。

此外，VP9包含10种不同的预测模型，在解码过程中高效地重建图像，并具有一系列增强流媒体视频内容可靠性的功能。这对于高清视频至关重要。全高清图像包含约200万像素，可能包含数百万种颜色构成单个帧，而一部电影则包含数十万个帧。Google已宣布计划在YouTube*上使用VP9处理4K内容。Google Play*商店也可能在其流媒体视频服务中使用VP9。

规划方法

我们团队的首要目标之一是定义测试用例。VP9适用于各种流媒体视频，但我们注意到，视频会议的内容帧与帧之间的变化通常比YouTube视频少。我们决定从更简单的视频会议场景入手。我们的计划是先验证视频会议的关键优化，然后再测试它们在更复杂的视频使用场景中的表现。

我们的首个架构目标是32位Android*上的Bay Trail。一旦我们在Bay Trail上实现了最佳的解码性能，我们将转向其他平台。

迎接挑战

我们的团队，包括一位首席工程师和一位架构师，使用CPU模拟器来识别现有代码中的热点。我们采用迭代式优化方法——利用内部工具和微架构知识识别潜在问题，编写代码并测量新解决方案的性能，然后进行代码审查。具体来说，在WebM/libvpx优化过程中，我们遇到了一些与前端相关的问题，这些问题将在下文进一步详述。这些问题很容易发现和修复，并可能为您的应用程序带来显著的性能提升。

MSROM指令流导致前端饥饿

我们在Silvermont微架构上发现的一个性能问题是过度使用pshufb指令。根据优化手册[1]，pshufb需要MSROM的解码器协助，其吞吐量和延迟为5个周期。

MSROM查找会在前端造成延迟，并限制每个周期解码的指令数量。在许多情况下，MSROM查找的开销是可以接受的（当后端无法以更高的速率消耗和执行uops时），但如果此类指令数量很高，当IDQ中没有uops时，性能可能会受到影响。

我们发现“vp9_filter_block1d16_h8_ssse3”函数[2]中过多的pshufb指令导致了上述问题。通常，pshufb指令会根据任意掩码重新排列向量寄存器中的字节。

我们深入研究了实际所需的操作（见下图），使用了两个pshufb指令。

我们意识到，使用四个简单的操作（punpcklbw、punpckhbw和两个palignr指令）就可以完成完全相同的操作，如下一图所示。

优化的代码可在[3]中找到，在函数级别实现了15%的实测加速。

大于8字节的指令

我们识别出另一个限制性能的前端特性。然而，与前一个例子不同的是，这是由微架构的特性引起的——“Silvermont微架构只能在指令超过8字节时每周期解码一条指令”[1]。

在这种特定情况下，mb_lpf_horizontal_edge_w_sse2_16[4]代码由于向量寄存器压力大以及向堆栈的多次加载/存储而受到影响，因此需要使用内存源的操作。

使用rsp寄存器会向指令编码添加一个额外的SIB字节，并生成大量超过8字节的指令。因此，前端吞吐量受到限制（略高于每周期解码1条指令），因此无法实现每周期2条向量指令的良好后端利用率。

通过使用rbp寄存器寻址堆栈，解决了此问题。这不会为指令添加SIB字节，并使我们实现了20%的函数级别加速。补丁提交仍在进行中。

第四个前缀

最后，但同样重要的是，我们在代码中必须应对的微架构特性是处理具有4个或更多前缀的指令时，解码延迟为3个周期。如您可能知道，Silvermont架构每周期可以解码多达2条指令，或者3个周期内解码多达6条指令。因此，3个周期只解码一条指令，这可能经常导致性能问题。

当使用任何上8个xmm寄存器（xmm7-xmm15）以及某些向量指令时，通常会添加第四个前缀，因为使用这些寄存器会为指令添加一个额外的REX前缀。pmaddubsw指令是这种情况的一个很好的例子[5]。具体来说，“pmaddubsw xmm1, xmm2”将导致以下编码“66 0F 38 04 …”，而“pmaddubsw xmm1, xmm16”将添加REX前缀——“66 41 0F 38 04 …”

通过限制这些特定指令的向量寄存器使用，我们在函数级别实现了25%的加速。

性能结果

总体结果非常出色。在64位模式下，该团队将用户级别性能提高了高达16%（6.2帧/秒），在32位模式下提高了约12%（1.65帧/秒）。这项测试包括对32位和64位GCC和Intel®编译器的评估，结论是Intel编译器在Intel® Atom™处理器上提供了迄今为止最佳的优化。当您将这种改进乘以数百万的观看者和数千个视频时，其意义是巨大的。Google的WebM团队也认识到这种性能提升极其显著。Google工程经理Frank Gilligan对团队的成功表示：“太棒了。看起来很好。我迫不及待地想尝试所有这些。”针对代号为Goldmont和Tremont的未来Intel Atom平台进行的测试，VP9优化带来了额外的收益。

虽然视频解码器在Intel® Core™处理器上已经高度优化，但在Intel® Atom™架构上效率并不高。现在，观看YouTube内容或进行视频会议可以带来更好的用户体验，具有更高的质量和无延迟。这项工作也很重要，因为越来越多的YouTube用户将在基于Intel®架构的设备上观看视频。该团队还提前识别并修复了64位Intel Atom平台上可能存在的性能问题，以免最终用户在设备上遇到。

这项成功经受住了时间的考验。我们的性能团队为最终用户体验带来了显著且持久的改进。在满足并超越32位Android的目标后，我们的团队拓宽了视野，并将范围扩展到包括64位环境，以应对64位Android的到来。

关于作者

Tamar Levy和Ilya Albrekht是软件和服务部门客户平台赋能团队的软件工程师，他们与个别客户合作，从事Windows*和Android媒体性能赋能应用程序项目。