Mesa 附带的 LLVMpipe (Lavapipe) 驱动在独显上导致 Vulkan 无法正常使用

[MingcongBai]

问题描述

在 Mesa 23.3.0 上（23.2.x 亦有此问题），如果系统安装了 Lavapipe Vulkan 驱动，会导致 Vulkan 在独显显卡加速可用的情况下，Vulkan 不可用：

mingcongbai@JellyCambarus [ ~ ] $ vulkaninfo
WARNING: [Loader Message] Code 0 : loader_scan_for_direct_drivers: The VK_LUNARG_direct_driver_loading extension was enabled but the pNext chain of VkInstanceCreateInfo did not contain the VkDirectDriverLoadingListLUNARG structure.
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 0.  Skipping ICD.
LLVM ERROR: Cannot select: 0x55558c354310: ch = store<(store (s128))> 0x55558c353f20, 0x55558c354070, 0x55558c3542a0, undef:i64
  0x55558c354070: v4f32 = BUILD_VECTOR ConstantFP:f32<0.000000e+00>, ConstantFP:f32<0.000000e+00>, ConstantFP:f32<0.000000e+00>, ConstantFP:f32<0.000000e+00>
    0x55558c354000: f32 = ConstantFP<0.000000e+00>
    0x55558c354000: f32 = ConstantFP<0.000000e+00>
    0x55558c354000: f32 = ConstantFP<0.000000e+00>
    0x55558c354000: f32 = ConstantFP<0.000000e+00>
  0x55558c3542a0: i64 = add nuw 0x55558c353f90, Constant:i64<16>
    0x55558c353f90: i64,ch = CopyFromReg 0x55558c353f20, Register:i64 %8
      0x55558c353eb0: i64 = Register %8
    0x55558c354230: i64 = Constant<16>
  0x55558c353dd0: i64 = undef
In function: sample
已放弃（核心已转储）

Lavapipe 驱动是由如下文件提供的：

/usr/lib/libvulkan_lvp.so
/usr/share/vulkan/icd.d/lvp_icd.loongarch64.json

调试操作

删除 Lavapipe 提供的两个驱动文件后，Vulkan 可正常使用，如图：

vulkaninfo 运行状态

vkcube 示例程序运行状态，留意终端输出中程序正确识别了显卡型号

运行环境

• 系统：AOSC OS
• Mesa 版本：23.3.0
• LLVM 版本：17.0.6
• 处理器平台：Loongson 3C5000
• 显卡：AMD Radeon RX 7600

[MingcongBai]

这个问题可能是 AOSC OS 的 Mesa 中 backport 的 ORCJIT LLVMpipe 支持补丁（编号 0001 - 0003）导致的，问题估计不在 Mesa 而在 LLVM。

[xen0n]

这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分，要么默认开了 la464 或者明确开了 LSX 等 attributes，要么探测了 host CPU 能力并动态开启了相应 attributes。

要 workaround 此问题，最简单的办法是暂时停止动态探测特性，并使用 generic CPU 型号

[Icenowy]

这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分，要么默认开了 la464 或者明确开了 LSX 等 attributes，要么探测了 host CPU 能力并动态开启了相应 attributes。

要 workaround 此问题，最简单的办法是暂时停止动态探测特性，并使用 generic CPU 型号

抱歉，是我擅自开了 LSX ……

[Icenowy]

Forcing "-lsx" is a workaround here (just leave neither "+lsx" nor "-lsx" seems to be not okay here because LLVM will still try to use LSX in this situations).

[MingcongBai]

这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分，要么默认开了 la464 或者明确开了 LSX 等 attributes，要么探测了 host CPU 能力并动态开启了相应 attributes。
要 workaround 此问题，最简单的办法是暂时停止动态探测特性，并使用 generic CPU 型号

抱歉，是我擅自开了 LSX ……

关闭 LSX 后确实没问题了，不过 -mlsx 确实是根据先前约定的处理器特性支持开启的，AOSC OS 全局开启 LSX 构建：

[xry111]

我觉得如果确定开 lsx 会出问题的话应该在 LLVM 把自动检测关掉并声明 LSX 是 experimental feature。

[xen0n]

Triage: LLVM 18 修复了 LSX 代码生成的崩溃问题，因此如果 Mesa 搭配上了 LLVM 18 或更高的版本，那么本问题应该就得到解决了

Triage: LLVM 18 has the LSX codegen crashes fixed, so this issue should be gone once Mesa is paired with LLVM 18 or greater.

[xen0n]

See: https://bugs.gentoo.org/929197