KhronosGroup / KhronosGroup/SPIRV-Registry

Missing ability to qualify struct members as Restrict?

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.