咨询SPIR-V中OpSDot的Packed Vector Format输入有符号性要求

启用OpSDot、OpUDot、OpSUDot的Packed Vector Format开关时，输入的32位标量整数参数的有符号性，是否需要和其被解释的8位分量的逻辑有符号性匹配？还是无论分量逻辑有符号性如何，打包后的32位标量都必须是无符号类型（类似WGSL的处理方式）？

困惑来源 #

• OpSDot和OpUDot的规范仅明确：输入必须为相同类型，且是32位整数（或向量），但未指定标量模式下的有符号性要求。未打包的向量场景中，OpSDot对应有符号向量、OpUDot对应无符号向量是明确的，但打包场景下，把4个有符号8位整数打包成32位标量时，将其视为无符号整数（仅作为位聚合）似乎更合理，因为此时标量的标准算术操作已无意义。
• 使用spirv-val验证时，两种有符号性的输入都被接受，甚至OpUDot的无符号打包点积也接受有符号32位整数输入，这让验证结果的可信度存疑。
• OpSUDot的规范明确区分了向量和标量场景：

  当向量1和向量2为向量时，向量2的分量必须具有Signedness为0。当向量1和向量2为标量整数类型时，必须指定Packed Vector Format以选择如何将整数解释为向量。
  仅针对未打包向量场景限制了第二个参数的有符号性，对标量（打包）场景未提及任何有符号性要求。

解答 #

从SPIR-V核心规范的设计逻辑和实际硬件行为的对齐角度来看：

1. Packed Vector Format本质是位聚合解释：启用该开关后，32位标量仅作为4个8位分量的位容器，其自身的有符号性属性不影响8位分量的逻辑有符号性——分量的有符号性完全由操作本身（OpSDot/OpUDot/OpSUDot）决定：
   • OpSDot会将32位标量拆解为4个有符号8位整数进行点积计算
   • OpUDot会将32位标量拆解为4个无符号8位整数进行点积计算
   • OpSUDot则按规则将第一个标量拆解为有符号8位分量、第二个拆解为无符号8位分量
2. 32位标量的有符号性不做强制要求：规范未限制标量的有符号性，是因为硬件在处理打包点积时，只会读取标量的原始位模式，不会对标量本身做有符号/无符号的算术处理。spirv-val接受两种输入的行为是符合规范的，并非验证器缺陷。
3. 与WGSL的差异：WGSL要求打包后的标量为无符号类型，属于WGSL自身的语法约束，而非SPIR-V规范的强制要求。在SPIR-V层面，只要输入是32位整数标量（无论有符号/无符号），配合Packed Vector Format开关，就能被正确解释为对应类型的8位分量向量。

总结：32位标量自身的有符号性不需要和8位分量的逻辑有符号性匹配，操作本身会决定拆解后分量的有符号性，标量仅作为位的载体存在。

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