升级LunarG SDK至1.0.68.0后SPIR-V出现InterlockedMax错误

这个问题的核心是新版LunarG SDK（1.0.68.0）的SPIR-V validator对原子指令的类型校验变得更严格，而旧版（1.0.65.0）没有严格执行这一规则。错误提示AtomicSMax: expected Result Type to be int scalar type明确指出：你使用的AtomicSMax指令要求结果必须是32位有符号整数标量，但你的着色器生成的SPIR-V不符合这个要求。

结合你提到的“使用Interlocked*方法时错误消失”的现象，问题大概率出在HLSL中Interlocked*函数的类型匹配上，下面是具体的排查和解决步骤：

1. 严格匹配Interlocked函数的类型 #

HLSL中的InterlockedMax有两个明确的版本：

• 针对有符号整数（int）：void InterlockedMax(int& target, int value)，对应SPIR-V的AtomicSMax指令，要求操作数必须是32位有符号标量。
• 针对无符号整数（uint）：void InterlockedMax(uint& target, uint value)，对应SPIR-V的AtomicUMax指令，操作数必须是32位无符号标量。

旧版SDK的validator可能允许混用类型（比如用int版本的InterlockedMax操作uint变量），但新版会直接报错。请检查你的着色器：

• 如果操作的是uint变量，必须确保调用的是InterlockedMax(uint&, uint)，而不是误用int版本。
• 反之，操作int变量时，必须传入int类型的value参数，不能依赖uint的隐式转换。

2. 确保目标变量是标量类型 #

AtomicSMax和AtomicUMax都只能作用于标量变量，不能是向量（比如int2、uint3）或者64位整数（long、ulong）。请确认你调用Interlocked*的目标变量是单个的int或uint，而不是复合类型。

3. 检查HLSL编译参数 #

如果你的着色器代码本身没问题，可能是编译命令的参数导致的：

• 确保使用的dxc编译器版本与新版LunarG SDK兼容（新版SDK通常会附带更新的dxc）。
• 添加明确的SPIR-V目标环境参数，比如-fspv-target-env=vulkan1.1，避免编译器生成不符合当前Vulkan版本的指令。
• 可以尝试添加-Od（禁用优化）编译，排查是否是优化阶段导致的类型错误。

4. 验证编译后的SPIR-V（可选） #

如果以上步骤都没解决问题，可以用LunarG SDK自带的spirv-dis工具反汇编你的.spv文件，搜索AtomicSMax指令，查看它的类型定义：

; 正确的AtomicSMax类型定义示例
%int = OpTypeInt 32 1
%ptr_int = OpTypePointer StorageBuffer %int
...
OpAtomicSMax %int %ptr_int %offset %scope %semantics %value

如果看到%int对应的是OpTypeInt 32 0（无符号）或者其他非32位有符号类型，那说明HLSL编译器生成了错误的指令，需要进一步调整着色器代码或编译参数。

内容的提问来源于stack exchange，提问作者SurvivalMachine