KhronosGroup / KhronosGroup/SPIRV-Registry
Missing ability to qualify struct members as Restrict?
- Dominant language
- HTML
- Stars
- 149
- Forks
- 99
- Avg merge
- 4d 21h
- Merged PRs (30d)
- 2
Description
GLSL spec says:
> The memory qualifiers **coherent**, **volatile**, **restrict**, **readonly**, and **writeonly** may be used in the declaration of buffer variables (i.e., members of shader storage blocks). When a buffer variable is declared with a memory qualifier, the behavior specified for memory accesses involving image variables described above applies identically to memory accesses involving that buffer variable. It is a compile-time error to assign to a buffer variable qualified with **readonly** or to read from a buffer variable qualified with **writeonly**.
SPIR-V spec says:
> **Restrict**
> Apply only to a memory object declaration, to indicate the compiler may compile as if there is no aliasing. See the Aliasing section for more detail.
Possibly relevant, from the change-log:
> Khronos SPIR-V Issue #408: (Re)allow the decorations **Volatile**, **Coherent**, **NonWritable**, and **NonReadable** on members of blocks. (Temporarily dropping this functionality was accidental/clerical; intent is that it has always been present.)
Was the intent to continue disallowing **Restrict** on members of blocks?
It's worth pointing out that glslang accepts GLSL code with such declarations, and turns them into what is technically invalid SPIR-V:
e.g.
```glsl
layout(std430, binding=1) coherent restrict buffer _PeakDetect_2_0 {
layout(offset=0) vec2 average;
layout(offset=8) int frame_sum;
layout(offset=12) int frame_max;
layout(offset=16) uint counter;
};
```
becomes:
```
OpName %_PeakDetect_2_0 "_PeakDetect_2_0"
OpMemberName %_PeakDetect_2_0 0 "average"
OpMemberName %_PeakDetect_2_0 1 "frame_sum"
OpMemberName %_PeakDetect_2_0 2 "frame_max"
OpMemberName %_PeakDetect_2_0 3 "counter"
...
OpMemberDecorate %_PeakDetect_2_0 0 Coherent
OpMemberDecorate %_PeakDetect_2_0 0 Restrict
OpMemberDecorate %_PeakDetect_2_0 0 Offset 0
OpMemberDecorate %_PeakDetect_2_0 1 Coherent
OpMemberDecorate %_PeakDetect_2_0 1 Restrict
OpMemberDecorate %_PeakDetect_2_0 1 Offset 8
OpMemberDecorate %_PeakDetect_2_0 2 Coherent
OpMemberDecorate %_PeakDetect_2_0 2 Restrict
OpMemberDecorate %_PeakDetect_2_0 2 Offset 12
OpMemberDecorate %_PeakDetect_2_0 3 Coherent
OpMemberDecorate %_PeakDetect_2_0 3 Restrict
OpMemberDecorate %_PeakDetect_2_0 3 Offset 16
OpDecorate %_PeakDetect_2_0 Block
```
Which mesa's SPIRV-to-NIR compiler, in turn, rejects as invalid:
```
SPIR-V WARNING:
In file ../src/compiler/spirv/spirv_to_nir.c:1073
Decoration not allowed on struct members: SpvDecorationRestrict
1552 bytes into the SPIR-V binary
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by comparing the GLSL and SPIR-V specification passages cited in the issue, then inspect glslang's generated decorations and Mesa's spirv_to_nir.c validation warning. Done means the specification's treatment of Restrict on block members is resolved and the relevant compiler behavior is made consistent with that decision.
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
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100