[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.

In questa issue migrata non sono indicati file sorgente, test o punti di ingresso. Inizia individuando il codice che emette gli operandi di memoria SPIR-V e confrontalo con la specifica NonPrivatePointer collegata; il lavoro è completato quando gli accessi al di fuori di Function e Private usano l’operando e i casi rilevanti hanno una copertura.