Open MingcongBai opened 7 months ago
这个问题可能是 AOSC OS 的 Mesa 中 backport 的 ORCJIT LLVMpipe 支持补丁(编号 0001 - 0003)导致的,问题估计不在 Mesa 而在 LLVM。
这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分,要么默认开了 la464
或者明确开了 LSX 等 attributes,要么探测了 host CPU 能力并动态开启了相应 attributes。
要 workaround 此问题,最简单的办法是暂时停止动态探测特性,并使用 generic
CPU 型号
这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分,要么默认开了
la464
或者明确开了 LSX 等 attributes,要么探测了 host CPU 能力并动态开启了相应 attributes。要 workaround 此问题,最简单的办法是暂时停止动态探测特性,并使用
generic
CPU 型号
抱歉,是我擅自开了 LSX ……
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).
这个问题确实是因为 LLVM 的 LoongArch SIMD 实现不完整而导致的。Mesa 跟 LLVM JIT interface 的部分,要么默认开了
la464
或者明确开了 LSX 等 attributes,要么探测了 host CPU 能力并动态开启了相应 attributes。 要 workaround 此问题,最简单的办法是暂时停止动态探测特性,并使用generic
CPU 型号抱歉,是我擅自开了 LSX ……
关闭 LSX 后确实没问题了,不过 -mlsx
确实是根据先前约定的处理器特性支持开启的,AOSC OS 全局开启 LSX 构建:
我觉得如果确定开 lsx 会出问题的话应该在 LLVM 把自动检测关掉并声明 LSX 是 experimental feature。
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.
问题描述
在 Mesa 23.3.0 上(23.2.x 亦有此问题),如果系统安装了 Lavapipe Vulkan 驱动,会导致 Vulkan 在独显显卡加速可用的情况下,Vulkan 不可用:
Lavapipe 驱动是由如下文件提供的:
调试操作
删除 Lavapipe 提供的两个驱动文件后,Vulkan 可正常使用,如图:
vulkaninfo
运行状态vkcube
示例程序运行状态,留意终端输出中程序正确识别了显卡型号运行环境