从视频编译入手 字节跳动助力RISC-V在服务器市场普及

7月18日，在第五届RISC-V中国峰会软件与生态系统分论坛现场，字节跳动软件工程师钱佳炎从多个维度深入介绍了该公司以X264为起点，在基于RISC-V的视频编译上的开发进展，以及目前的问题。

钱佳炎指出 ，虽然FFmpeg在视频解码器领域虽有一定进展，但其软件生态差距仍然显著。除了FFmpeg，像X264这类独立仓库对FFmpeg的支持尚不完善。字节跳动服务器团队着眼于推动内部服务器领域的RISC-V生态发展，进而助力RISC-V在服务器市场的普及。而抖音作为字节跳动的核心产品，视频编译是关键领域，因此团队选择以X264为起点展开探索。

X264仓库是编码器领域的典型代表，其软件结构包含一套由C代码编写的编码器核心流程，这是编码器策略的核心部分。同时，有一批基于编码器协议的核心算法，这些算法具有通用扩展性，针对不同架构如X86、ARM等都有特定实现。字节跳动团队的主要工作是对RISC-V实现进行优化，其中绝大部分实现采用手写汇编，工作量巨大，另一小部分工作则聚焦于注册函数机制的探索，最终目标是使X264在RISC-V架构上的性能达到对标水平。

X264的抽象计算Pattern具有独特之处。其底层绝大多数算子Pattern相似，以处理720P图像块为例，会在像素块中选取4×4到16×16不等的小矩阵进行计算。由于CPU上不连续的内存请求无法一次性完成，传统X86和ARM CPU更适合高并发的窄向量实现，因此ARM在编码器领域性能更优，而X86则表现欠佳。

以一个典型算子实现为例，对比RVV实现案例和NIO表现，RVV通过Stride load实现连续计算，在乱序窄向量CPU设计上具有优势。然而，当前许多CPU采用宽向量两发射顺序的512bit实现，若按128bit计算则可能带来性能问题。尽管在512bit参数下这套实现有一定优势，但目前仍在推动硬件增加特定约束，以解决指令性能依赖128bit的问题。

X264中大约有两三百个类似算子。由于当前缺乏高性能的RISC-V CPU，字节跳动在RISC-V社区建议下，采用C实现和RVV实现的加速比来评估性能，以相对加速效果替代绝对性能。通过SpaceMIT K1平台进行测试，虽然其绝对性能远不如Arm库，但至少证明了大部分实现方向正确。同时，在对比不同计算加速比时，发现RVV指令与NIO仍存在较大差距。

在优化过程中，字节跳动发现了多个指令集瓶颈。首先是in-register transpose问题，即将数据从行转换为列，目前通过trn1/trn2指令组合实现，复杂度为nlogn，且缺乏与ARM对标的指令。其次是absolute difference问题，需要四条指令实现。此外，Signed saturate and Narrow to Unsigned等问题也较为突出，RISC-V标准中从标量转为向量的处理方式与ARM不同，需要额外指令清零。

发现问题后，字节跳动团队积极推动指令集优化。在RISE提出问题，收集生态开发者反馈，并寻求上一届主席在向量集方面的帮助。在Vector Sig详细讨论差距，使其成为2025年重点工作之一。同时，团队提出了Zvabd问题，目前该提议正在流程中。

然而，与ARM完备的指令集相比，RISC-V仍有差距。这是因为当前社区对新扩展的要求注重实用主义，希望指令对应用集有明确价值，且在功能、向量变体和数据类型上尽量最小化。

基于开发过程中的讨论和优化，字节跳动团队发现软件生态面临一些问题。首先是指令集瓶颈，若更多软件需求方如字节跳动积极参与社区讨论，将有助于更快补齐指令集差距；其次是vector len的碎片化问题，RVV最初设计希望一套代码适配任意vlen，以提升硬件灵活度，但实际追求性能最优时，每个特定vlen甚至每套CPU都需要独立优化，这在视频编码领域尤为严重，因为大部分向量化代码仓传统上采用手写汇编，碎片化问题突出，目前X264仓库已开始分化vlen的合入；最后是验证问题，当前需要更好的验证机制来确保软件生态的稳定性和性能。