Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GLSL: Array sizes that use expressions on specialization constants #18

Closed
tangent-vector opened this issue Jun 15, 2017 · 1 comment
Closed
Labels
kind:enhancement a desirable new feature, option, or behavior

Comments

@tangent-vector
Copy link
Contributor

Vulkan GLSL allows for the size of an array to depend non-trivially on a specialization constant:

layout(constant_id = 0) const int N = 5;

float foo[N]; // trivial dependence

float bar[ (N+ 15) / 4 ]; // non-trivial dependence

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:

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

  2. 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.

@tangent-vector tangent-vector added glsl inactive:wontfix out of scope, or not desired labels Jun 15, 2017
@tangent-vector 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
@tangent-vector tangent-vector added this to the Backlog milestone Jun 15, 2017
@tangent-vector tangent-vector removed the inactive:wontfix out of scope, or not desired label Jun 15, 2017
@tangent-vector tangent-vector removed this from the Backlog milestone Oct 11, 2017
@tangent-vector tangent-vector added the kind:enhancement a desirable new feature, option, or behavior label Oct 11, 2017
@tangent-vector
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:enhancement a desirable new feature, option, or behavior
Projects
None yet
Development

No branches or pull requests

1 participant