Comments (8)
GLSL was defined with copy-in/copy-out semantics, to unambiguously avoid all such problems, but then some objects got treated like references or handles to other things.
I think we need to be more clear when something is acting on a copy and when it is acting on the original.
from glsl.
I also think it is safer to revert the recent change until we have this fully sorted out.
Edit: The change was very syntactic, equating two syntaxes, so the underlying issue is the same either way.
The change just made these two the same:
// 1
layout(set = 0, binding = 0, std430) readonly restrict buffer A {
float b;
} a;
// 2
layout(set = 0, binding = 0, std430) restrict buffer A {
readonly float b;
} a;
Based on this language from the spec:
memory qualifiers may also be used in the declaration of shader storage blocks. When a
block declaration is qualified with a memory qualifier, it is as if all of its members were declared with the same memory qualifier.
from glsl.
Is there anything holding back the revert? I'm afraid that we wouldn't be able to get any recent glslang changes into the CTS until this issue is resolved.
from glsl.
The revert does not change the fundamental problem the issue is about.
Do you want glslang to relax the read-only thing in general, not just for a failed inheritance?
from glsl.
I understand that the revert doesn't solve the fundamental problem but I'm trying to solve practical problem of not being able to update glslang in the CTS. New restrictions break shader compilation.
Personally, I would prefer to relax the read-only thing in general but I assume it would require some change in the specification.
from glsl.
When the thing passed is effectively a pointer or handle to something else, the readonly is really a modifier on what is pointed to. Passing a readonly handle to a non-readonly in parameter that then goes and updates what was pointed to needs to be disallowed.
My mental model for this is something like "Reading a readonly buffer member returns an rvalue. values passed to an in parameter must be rvalues. Therefore it is valid to pass a readonly buffer member to an in parameter."
I think that works only because members don't happen to (currently) be pointers to other things, while the real distinguishing characteristic should be that it is either:
A. Essentially a pass-by-reference (or pointer, or handle, whatever the term of the moment is). Includes atomic counters, anything atomic operations act on, buffers as a whole, and textures/samplers/images (and futuristically interpolants that interpolate*() functions might be applied to) .
or
B. Everything else; normal stuff, where the entire object in question is [semantically] copied in and copied out, such that the function is operating only on the copy.
For B, readonly should be ignored when passing to in and inout and writeonly should be ignored when passed to out, as Jeff said, I'm just slicing it as A vs. B rather than block member vs. not block member.
I think glslang should move now in that direction as it is much closer (if not exactly) to spec. intent, and while it would technically be a spec. bug, the previous state of glslang for this was also a spec. bug, and adhering to the spec. is clearly wrong and breaks real things.
from glsl.
I pushed KhronosGroup/glslang@92f5afd as the least of evils until we have agreement on correct approach.
from glsl.
We discussed this in the OpenGL/ES meeting today. @johnkslang agreed to propose a spec change incorporating his proposal in #83 (comment).
from glsl.
Related Issues (20)
- Another descriptor binding model (new data type idea)
- Symbolic/Automatic Differentiation Implementation in glsl
- Please rename default branch from 'master' to 'main' per Khronos policy HOT 4
- Clarify "Boolean expression" for binary logical operators HOT 7
- Support for Vertex/Fragment layout blocks
- Is GLSL had some online document? HOT 2
- Khronos GLSL grammar 4.60.7 has missing parameter-type for "P" in "textureGrad" HOT 2
- GLSL grammar allows for statements like "float;" but does not say they're invalid HOT 1
- GL_KHR_cooperative_matrix.txt not public HOT 1
- Vulkan reserved keywords are missing from the GLSL ES 3.2 Spec HOT 1
- GLSL Specification 4.60.8: incorrect formatting HOT 1
- halfBitsToUInt16 is missing HOT 4
- GL_EXT_shader_explicit_arithmetic_types misspelling of halfBitsToUInt16?
- GL_KHR_vulkan_glsl allows gl_VertexIndex in any stage
- [GLSL 4.6 Specification] Clarify the translation from UTF-8 scalar values to the corresponding character set tokens HOT 3
- Clarify GLSL for-loop scoping rules HOT 2
- GLSL_NV_mesh_shader.txt lacks a figure (figure 3.1)
- Clarify compilation of unbound array
- Description of texelFetch erroneously implies the lod parameter can be omitted HOT 1
- Variables of opaque types should be allowed
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from glsl.