search

KhronosGroup / MoltenVK

MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run on macOS, iOS and tvOS.
Apache License 2.0
4.76k stars 419 forks source link

OpAtomicSMax behaves as unsigned #2194

Closed giomasce closed 4 months ago

giomasce commented 6 months ago

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 commented 6 months ago

This should be filed on SPIRV-Cross.

giomasce commented 4 months ago

I can confirm this is fixed in 1.2.9.