[Migrated] Unsynchronized memory accesses outside of `Function`/`Private` need to use `NonPrivatePointer`.

Issue automatically imported from old repo: https://github.com/EmbarkStudios/rust-gpu/issues/838
Old labels: t: bug,s: qptr may fix
Originally creatd by eddyb on 2022-01-09T14:30:48Z

The description from the spec of NonPrivatePointer is:

NonPrivatePointer
The memory access obeys inter-thread ordering, as specified by the client API.

Missing before version 1.5.

My understanding is that with NonPrivatePointer, unsynchronized accesses can be used to access the same memory from different threads, as long as there is a barrier (or an equivalent atomic access) separating them - AFAICT, this matches Rust's concurrency semantics (likely rooted in the C++11 memory model, but I'm far from an expert).

To give a practical example, this is what allows Mutex<SomeData> to work, as well as passing Box<SomeData> between threads (or even &mut SomeData, with scoped threads - rayon relies on this a lot) - all accesses to SomeData will be unsynchronized, but they can't race between threads because of the synchronization used to get access to the pointer in the first place.

Without NonPrivatePointer, however, opting into the Vulkan memory model isn't enough to make anything other than atomic accesses thread-safe. Even something as potentially-common as reading data written per-invocation, from a single chosen invocation (i.e. the "join" step in a "fork-join" model), would be UB unless the per-invocation writes and the single-chosen-invocation read, are all atomic (and the data would only be considered available after the shader completes, to the Vulkan host, i.e. the CPU).

Overall it seems like a strange historical accident, but the default in SPIR-V doesn't seem compatible with Rust semantics.

The safest thing would probably be to always add NonPrivatePointer, and remove it only for Function and Private accesses (and maybe anything that's read-only memory?) in a pass - that way, it's conservative if that pass misses anything, instead of the opposite.

There's probably also a similar issue involving NonPrivateTexel and writable images, but I haven't looked closer.

En este issue migrado no se nombran archivos fuente, pruebas ni puntos de entrada. Empieza localizando el código que emite operandos de memoria SPIR-V y compáralo con la especificación NonPrivatePointer enlazada; se considera terminado cuando los accesos fuera de Function y Private usan el operando y los casos relevantes tienen cobertura.