search

KhronosGroup / glslang

Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator.
Other
2.98k stars 824 forks source link

Readonly decorations are only set on members of the struct type #792

Open gwihlidal opened 7 years ago

gwihlidal commented 7 years ago

Glslang only sets the readonly flags on members of the struct type. While it seems legal to do so, this is really awkward for reflection (i.e. spirv_cross) A workaround (like https://github.com/KhronosGroup/SPIRV-Cross/pull/139 - which likely won't reach mainline, since it's reporting decorations that don't exactly exist), is to check if you're querying an SSBO, and poke into the members to find the flags, which is kind of ugly.

If would be great if glslang could promote these flags up to the parent, instead.

Thanks, Graham

johnkslang commented 7 years ago

GLSL 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).

SPIR-V says

NonWritable Apply to an object or a member of a structure type...

Shouldn't all tools be supporting that? It would seem strange to have glslang not represent GLSL correctly instead.

johnkslang commented 7 years ago

This is all set up to support different flags on different members.

Maybe there should be a post process that

Is that the request? It would not fix other tools in the general sense, they would still have bugs when things vary per member.

Or, this is a request against specifications to not allow such variance? This would need be made against the issue-tracking for each involved specification (GLSL, Vulkan, SPIR-V).

Or, is this just about HLSL run-time, where it's the only member, and maybe when glslang is synthesizing the composite, it can put the flag on the composite instead? That might trigger new paths in drivers.

chaoticbob commented 7 years ago
  • checks to see if for any flag, all members of a composite have the same setting for the flag, and
  • if so, promote the flag out of the members up to the composite?

Is that the request? It would not fix other tools in the general sense, they would still have bugs when things vary per member.

Out of curiosity, what's an example in which the first of the above isn't true? i.e. where members have different flags? Maybe when you write to one member out of many?

Seems like in the case of SSBO reflection, it would be less work for tasks, like figuring out if an SSBO is a SRV or UAV, if one could determine RO/RW state from the composite.

johnkslang commented 7 years ago

Out of curiosity, what's an example in which the first of the above isn't true? i.e. where members have different flags?

We'd need to be clear about the space of choices here. SPIR-V certainly has lots of decorations that could appear on some members and not others, especially since GLSL lets users declare things that way. RelaxedPrecision, RowMajor, ColMajor, ArrayStride, MatrixStride, BuiltIn, NoPerspective, Flat, Patch, Centroid, Coherent, NonWritable, NonReadable, and Uniform all seem, at first glance, like they could vary per member.

Maybe when you write to one member out of many?

Generally, the decorations are not tracking how something got used, but are tracking how they were declared. A front-end would likely do semantic error checking on consistency between declaration and use, but not back-declare based on use (though some HLSL difficulties could end up that way.)

Are we really trying to declare an object as read only based on where or not any writes to it occurred?

It would depend on the source language whether such declarations/decorations are allowed to vary per member.

If something is actually wrong in this space, we probably need a concrete example to discuss.

chaoticbob commented 7 years ago

Are we really trying to declare an object as read only based on where or not any writes to it occurred?

I don't think so.

For the specific case that @gwihlidal referenced - during reflection, it's helpful to know if the SSBO is an UAV or a SRV. So the most that probably needs to happen is if one can determine if a SSBO is read or read/write from a decoration.

Is there a simpler way to handle this?