OpAtomicSMax behaves as unsigned

[giomasce]

It seems that MoltenVK executes OpAtomicSMax as its unsigned counterpart, and similarly for OpAtomicSMin. I discovered this while triaging vkd3d test failures (specifically, test_atomic_instructions()), but I also created a "minimal" (in the Vulkan sense) example which is attached (it doesn't properly do the portability subset extension dance, but hopefully that shouldn't be relevant). I current don't know any "real life" application impacted by the problem.

On MoltenVK (Apple Silicon M2 MacBook) the test program prints:

Final value: ffffffff

while I would expect (and I can see on other implementations) zero.

Hopefully the Vulkan boilerplate is obvious enough and you only need to care about the SPIR-V source and main function. The attachment has extension .txt because for some reason .cpp is not allowed.

I noticed that the generated MSL code indeed changes if I change the SPIR-V operator, but the result ends up being the same; with OpAtomicSMax I can see:

uint _17 = uint(u0.atomic_fetch_max(uint(0), int(4294967295u)).x);

and with OpAtomicUMax:

uint _17 = imageAtomicMax(u0, 0, 4294967295u);

I don't know enough about Metal to say whether the first result is correct.

[cdavis5e]

This should be filed on SPIRV-Cross.

[giomasce]

I can confirm this is fixed in 1.2.9.