You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GLSL spec language around this stuff is messy, and gives the impression that somebody worked backwards from the implementation in glslang. The basic behavior in glslang (which is now the "correct" behavior via spec) is:
Two array types, with the equivalent element types, that use specialization constants in their sizes are equivalent if and only if their sizes are specified using the exact same specialization constant (no math on the constant is allowed, not even N +1). All other cases are deemed not equivalent (even when syntactically identical).
Computed layout information as exposed in, e.g., SPIR-V or a reflection API will always be based on the "default" value for the specialization constant, and it is up to the user to carefully avoid cases where this will lead to incorrect behavior (e.g., don't put an array with speciaziation-constant-based size in the middle of something).
Item (1) is unfortunate, but understandable. Handling such things "right" means building a more complete dependent type system, and most people are going to back away from that. I'd like Slang to eventually do a better job, and at least incorporate a very basic "solver" to check for obvious algebraic identity. This would mean going against the GLSL spec, but compatibility with GLSL is a non-goal for Slang.
Item (2) is just plain dangerous. At some point it would be good to at least emit a warning in cases where the user has done something that could cause problems. A good policy would be to treat an array that uses a specialization constant a bit like an array with no statically-specified size (float foo[]), and only allow it at the end of a structure, etc.
I'd like to ensure that the Slang reflection API never lies to people.
For now, I'm considering all of this mess out of scope, so this issue only exists to provide a backlog item.
The text was updated successfully, but these errors were encountered:
tangent-vector
changed the title
Handle array sizes that use expressions on specialization constants
GLSL: Array sizes that use expressions on specialization constants
Jun 15, 2017
Slang no longer supports GLSL input, so this should no longer be a relevant issue.
The underlying problem would arise again if we ever allow the user to write arrays where the size comes from a generic parameter (including a global-scope generic parameter).
Vulkan GLSL allows for the size of an array to depend non-trivially on a specialization constant:
The GLSL spec language around this stuff is messy, and gives the impression that somebody worked backwards from the implementation in
glslang
. The basic behavior inglslang
(which is now the "correct" behavior via spec) is:Two array types, with the equivalent element types, that use specialization constants in their sizes are equivalent if and only if their sizes are specified using the exact same specialization constant (no math on the constant is allowed, not even
N +1
). All other cases are deemed not equivalent (even when syntactically identical).Computed layout information as exposed in, e.g., SPIR-V or a reflection API will always be based on the "default" value for the specialization constant, and it is up to the user to carefully avoid cases where this will lead to incorrect behavior (e.g., don't put an array with speciaziation-constant-based size in the middle of something).
Item (1) is unfortunate, but understandable. Handling such things "right" means building a more complete dependent type system, and most people are going to back away from that. I'd like Slang to eventually do a better job, and at least incorporate a very basic "solver" to check for obvious algebraic identity. This would mean going against the GLSL spec, but compatibility with GLSL is a non-goal for Slang.
Item (2) is just plain dangerous. At some point it would be good to at least emit a warning in cases where the user has done something that could cause problems. A good policy would be to treat an array that uses a specialization constant a bit like an array with no statically-specified size (
float foo[]
), and only allow it at the end of a structure, etc.I'd like to ensure that the Slang reflection API never lies to people.
For now, I'm considering all of this mess out of scope, so this issue only exists to provide a backlog item.
The text was updated successfully, but these errors were encountered: