KhronosGroup / KhronosGroup/SPIRV-Registry

`NonWritablePointer` and `NonStorablePointer` for BDA ? Motivation similar to `Aliased`

Open
#392 2 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.