[Migrated] Unsynchronized memory accesses outside of `Function`/`Private` need to use `NonPrivatePointer`.
まだ誰も着手していません。
- 主要言語
- Rust
- スター
- 3.4k
- フォーク
- 126
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
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.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
この移行された issue では、ソースファイル、テスト、エントリポイントが指定されていません。まず、SPIR-V メモリオペランドを出力するコードを見つけ、リンクされている NonPrivatePointer 仕様と比較してください。Function と Private の外部のアクセスがオペランドを使用し、関連するケースがカバレッジに含まれていれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- rust
- 領域
- compilers
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 30/100