KhronosGroup / KhronosGroup/SPIRV-Registry
`NonWritablePointer` and `NonStorablePointer` for BDA ? Motivation similar to `Aliased`
- Dominant language
- HTML
- Stars
- 149
- Forks
- 99
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 2
Description
The problem is similar to annotating that a BDA aliases, this is why `AliasedPointer` and `RestrictPointer` exists in SPIR-V.
They tell us that its not the pointer given out by `OpVariable` which may alias memory locations when used, but the pointer stored at the location pointed to by `OpVariable` can aliasmemory locations when used (because there will be two `OpLoad` or one `OpLoad` and one `OpStore` instructions chained together and its about the second one).
So with regards to `NonWritable` and `NonReadable` we need a similar solution to let the compiler know a BDA won't be used in certain ways.
Right now I can let the compiler know that an SSBO will be readonly, but not BDA.
Another and cleaner way would be to bake this into the declared BDA pointer type, like a `const` decoration on a pointer in C or C++.
Could be done either via decoration of the `OpType` or simply by allowing one more operand to `OpType` when its a `PhysicalStorageBuffer` pointer.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the existing AliasedPointer, RestrictPointer, NonWritable, and NonReadable SPIR-V definitions referenced in the issue. Compare decorating OpType with adding an operand to PhysicalStorageBuffer pointers, then establish the semantics and validation needed for BDA read/write restrictions. Done means a specification approach has been selected and documented.
Written by the indexing model from the issue text.
Assessment
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100