Specialization Constant as array size causes validation error

[karl-lunarg]

Issue by wobakj (MIGRATED)
Tuesday Mar 14, 2017 at 22:08 GMT
Originally opened as KhronosGroup/Vulkan-LoaderAndValidationLayers#1580

---

On drawing, the following error is triggered: Descriptor in binding #0 at global descriptor index 1 is being used in draw but has not been updated
The error appears regardless of the actual value of the constant. No error is triggered when using a "normal" constant variable with identical value instead. This behaviour appears at least for sampler, texture and buffer arrays.

[karl-lunarg]

Comment by wobakj (MIGRATED)
Thursday Jun 08, 2017 at 21:38 GMT

---

This issue can be closed. I now realized that it was caused by an incorrect automated building of the DescriptorSets in my application.

[karl-lunarg]

Comment by chrisforbes (MIGRATED)
Friday Jun 09, 2017 at 01:24 GMT

---

You may have had another issue with your code, but we're still doing the wrong thing in validation with specialization. This is still on my plate.

[mark-lunarg]

@chrisforbes, can you add some context about what needs to be done here?

[chrisforbes]

Right -- the remaining work here is to apply the SPIRV-Tools specialization passes before doing any analysis.

[jeremy-lunarg]

This is now covered by PR #1166.

[jeremy-lunarg]

We discovered an issue with PR #1166. Specialization of types defined in an extension is causing the optimizer to crash. We're working on a fix for the optimizer and then I'll reapply this patch.

I'm currently working on two patches in the spirv-tools optimizer which will allow this patch to be reapplied. First, I'm adding support for the SPV_NV_cooperative_matrix extension to the optimizer. It was supported by the validator but not by the optimizer. This will fix the tests in validationlayers that were breaking when I originally applied this patch.

Second, there's a larger issue with the way the optimizer handles specializations of unrecognized types. It currently logs the error internally and terminates the process. I believe a custom message consumer can be used as a stop-gap, but I think a better long-term alternative is to return to the caller after a failed optimization pass.

[jeremy-lunarg]

Fixed by #1344.

The SPIR-V optimizer (#2927) has been patched to handle existing extended types, and I've updated the patch in #1344 to log errors when future unrecognized/extended types are encountered.