SPIR-V 规范为操作、和定义了一个可选的打包向量格式开关。使用时，该操作的另外两个输入必须分别为 32 位整数，然后将其解释为 8 位整数的打包 4 维向量。OpSDotOpUDotOpSUDot
我的问题
在“打包矢量格式”情况下，这些标量 32 位整数参数的符号是否必须与其 8 位分量的（逻辑）符号匹配，或者打包的 32 位标量是否必须是无符号的（例如，在 WGSL 中的情况）？
我为什么对此感到困惑
和的规范OpSDot仅OpUDot规定“向量 1 和向量 2 必须具有相同的类型”，并且它们“必须是 32 位整数 [...] 或向量”，但并未明确规定它们是否必须带符号。如果它们是（未打包的）向量，那么在我看来，显然 和OpSDot期望 是带符号向量，而OpUDot和 期望 是无符号向量。但是，当将四个带符号的 8 位整数打包成一个 32 位标量时，我认为将结果视为无符号整数（就像在 WGSL 中一样）更为自然，因为此时，它只是一个“位的集合”，标准算术运算对它来说毫无意义。
使用 进行验证spirv-val似乎无论如何都可以接受，但它甚至接受带有符号的32 位整数输入，用于与进行无符号打包点积OpUDot，这在我看来很奇怪，所以我不信任这里的验证器。更让我困惑的是， （执行混合有符号/无符号整数点积）的规范OpSUDot确实明确指出第二个参数必须是无符号的，但它限定这仅适用于两个参数都是（解包）向量的情况：
[...]当向量 1 和向量 2 为向量时，向量 2 的分量的符号性必须为 0。[← 如果输入为（解包）向量，则定义符号性]
当向量 1 和向量 2 为标量整数类型时，必须指定打包向量格式来选择如何将整数解释为向量。[← 参数为“标量整数类型”（即打包）的情况将另行讨论，无需指定符号]
（重点和注释由我[...] 撰写。）
SPIR-V 规范对于有符号和无符号的理解基本上是这样的……它并不关心。除非操作码明确指定“无符号”或“有符号”，否则它并不关心使用哪种。
在您提到的混合情况下，它确实关心。但它只关心操作码的一种非常特殊的用法。对于该操作码的所有其他情况，它都不关心。