我在内核中找不到太多使用 SIMD 指令(如 SSE/AVX)的地方(除了一个用来加速 RAID6 奇偶校验计算的地方)。
Q1) 有什么具体原因,还是只是缺少用例?
Q2) 如果我想使用 SIMD 指令,比如设备驱动程序,今天需要做什么?
Q3)将像ISPC这样的框架合并到内核中会有多难(仅用于实验)?
我在内核中找不到太多使用 SIMD 指令(如 SSE/AVX)的地方(除了一个用来加速 RAID6 奇偶校验计算的地方)。
Q1) 有什么具体原因,还是只是缺少用例?
Q2) 如果我想使用 SIMD 指令,比如设备驱动程序,今天需要做什么?
Q3)将像ISPC这样的框架合并到内核中会有多难(仅用于实验)?
保存/恢复 FPU(包括 SIMD 矢量寄存器)状态比仅整数 GP 寄存器状态更昂贵。在大多数情况下,这根本不值得付出代价。
在 Linux 内核代码中,您所要做的就是围绕您的代码调用kernel_fpu_begin()
/ 。kernel_fpu_end()
这就是 RAID 驱动程序所做的。 请参阅http://yarchive.net/comp/linux/kernel_fp.html。
x86 没有任何面向未来的方法来保存/恢复一个或几个向量寄存器。(除了xmm
使用传统 SSE 指令手动保存/恢复寄存器之外,如果用户空间的任何 ymm/zmm 寄存器的上半部分变脏,可能会导致Intel CPU 上的 SSE/AVX 转换停止)。
传统 SSE 起作用的原因是,当英特尔想要引入 AVX 时,一些 Windows 驱动程序已经这样做了,所以他们发明了转换惩罚的东西,而不是让传统 SSE 指令将 ymm 寄存器的高 128b 归零。(有关该设计决策的更多详细信息,请参阅此内容。)因此,基本上我们可以将 SSE/AVX 转换惩罚混乱归咎于仅 Windows 二进制驱动程序。
关于非 x86 架构的 IDK,以及现有 SIMD 指令集是否具有面向未来的方法来保存/恢复将继续适用于更长向量的寄存器。如果扩展继续使用多个 32 位 FP 寄存器作为单个更宽寄存器的模式,ARM32 可能会。(例如q2
由s8
through组成。)因此,如果 256b NEON 扩展只是让您将 2 个寄存器用作一个 256b 寄存器,s11
那么保存/恢复几个q
寄存器应该是面向未来的。q
或者,如果新的更宽向量是分开的,并且不扩展现有寄存器。