specializer: allow unused fully-constrained interface variables. #729
Conversation
tests/ui/dis/issue-723.rs
Outdated
| use spirv_std as _; | ||
|
|
||
| #[spirv(closest_hit)] | ||
| pub fn test_closest_hit(#[spirv(object_to_world)] _object_to_world: [glam::Vec4; 3]) {} |
There was a problem hiding this comment.
Probably want to use a slightly modified test case, object_to_world requires an OpTypeMatrix on vulkan and so it's going to give an error when compiletest has target env of vulkan.
There was a problem hiding this comment.
Ah huh I haven't been running cargo compiletest with any flags lately because U thought Vulkan was the default.
eddyb
force-pushed
the
specializer-dead-vars
branch
from
a14826d
to
87cfce0
Compare
tests/ui/dis/issue-723.rs
Outdated
| use spirv_std as _; | ||
|
|
||
| #[spirv(closest_hit)] | ||
| pub fn test_closest_hit(#[spirv(object_to_world)] _object_to_world: [glam::Vec4; 3]) {} |
There was a problem hiding this comment.
Oh, sorry, I wrote the wrong code on #723.
I believe the type of _object_to_world should be [glam::Vec3; 4] (the same layout of Affine3A).
Since in glsl, gl_ObjectToWorldEXT[3][2] passes but emits out of range error when gl_ObjectToWorldEXT[2][3].
There was a problem hiding this comment.
I'm not using that test anymore, because of #729 (comment), anyway.
eddyb
force-pushed
the
specializer-dead-vars
branch
from
87cfce0
to
1a8084e
Compare
Fixes #723.
For a bit of background, this is what happens for e.g. an
Inputinterface variablex: f32, during inference/specialization ofOpTypePointerby storage class:We're in a weird situation, where
%xis fully determined to always be%x<Input>, because of the typing rule ofOpVariable S: (OpTypePointer S _)(i.e. the redundancy of the storage class), but it still started out as "generic", and its type is an application of a "generic", so we have to treat it as such for consistency.This isn't normally a problem, as any use of
%xwill be forced to instantiate%x<Input>, and so theOpEntryPointwill rely on that instance to replace its use of%xwith%x<Input>.However, if
%xhappens to be unused in the actual entry-point function, we would've panicked, before this PR, as theOpEntryPointcouldn't use any existing instances.This PR works around that by "simply" instantiating any interface variables listed in
OpEntryPoint, that have all of their "storage class parameters" fully constrained to concrete storage classes (and therefore require no inference/specialization).