Vulkan memory model spec details 🤓👆

[inner-daemons]

Checkout this cool thing: https://github.khronos.org/SPIRV-Registry/extensions/KHR/SPV_KHR_vulkan_memory_model.html

Relevant:
#4444
#1545

In #8251 we added cooperative matrix support which requires the vulkan memory model, so we enabled it. The vulkan memory model isn't supposed to change driver behavior but rather specify it more precisely. Unfortunately, we are not in compliance with it.

Every memory access now must specify "memory semantics," for example for workgroup memory/storage buffers would need NonPrivatePointerKHR to indicate that the memory access might depend on/affect other invocations. Also it will need to say if the reads/writes should be made visible.

We've known for a while in #4444 that storage buffers are not safely usable across invocations quite like workgroup memory. I believe this now also applies to workgroup memory however in shaders that make use of cooperative matrices. For that reason I think #8251 can be considered a regression.

[teoxoy]

So this issue is tracking the fact that we don't emit any of the necessary memory semantics but we enable the extension if the cooperative matrix feature is requested?

[inner-daemons]

@teoxoy Sort of, thats what triggered this. But this was created so we could talk about the details of the vulkan memory model but neither I nor anybody else actually wanted to do that so its just been rotting since.

The main point here is that by default memory is underspecified so you generally just assume it does reasonable things. This extension makes it more rigorous but also requires that you tell it exactly what it needs to do, which we don't. So shaders that happen to use cooperative matrix will technically have many memory accesses turned into undefined behavior.

In practice this probably doesn't matter much.