Metal does not support sizing arrays in shaders with Spec Constants

[cdavis5e]

In MSL, it is not possible to specify an array size using a variable in the constant address space. Because Metal function constants are variables in this space, this means that the size of an array cannot be a function constant. This is particularly surprising, given that several other things, including binding numbers of resources, can be function constants, which one would not expect given that arrays cannot be sized with function constants.

This means that, on Portability implementations over Metal, we won't be able to support shaders that use Specialization Constants to size arrays.

[kvark]

Not sure I understand why you want this to be a VkPI limitation. You have the constant value when the pipeline is created, and this is where you are generating MSL. What's stopping you from just putting the value of the constant into the MSL source?

[billhollings]

What's stopping you from just putting the value of the constant into the MSL source?

Thanks for identifying that possibility.

Exploring possible...but likely heroic...design options for this:

1. Implementation detects the requirement, and resubmits SPIRV to SPIRV-Cross with the specialized value as part of the SPIRV-Cross API?
2. SPIRV-Cross detects the requirement, and returns MSL that has contains some kind of printf kind of substitution tags which the implementation then invokes with the specialized values?
3. Implementation detects the requirement, and does some kind of search and replace on the completed MSL returned by SPIRV-Cross (which say contains a default value), with the specialized values?
4. Something better I'm not thinking of yet?

[billhollings]

Other considerations:

• This is on our list of feature requests submitted to Apple.
• How significant are the use-case requirements for this (vis-a-vis need for heroics)?

[cdavis5e]

• How significant are the use-case requirements for this (vis-a-vis need for heroics)?

Well, it turns out, there are tests in the CTS which do this. Many of the subgroup tests, for example. If we want MoltenVK to be a certified implementation of VkPS, we're going to have to implement this. And when gfx-rs gets subgroup support, they'll have to support it, too.

[grovesNL]

Implementation detects the requirement, and resubmits SPIRV to SPIRV-Cross with the specialized value as part of the SPIRV-Cross API?

Is there a reason we won't be able to use the existing fallback paths (https://github.com/KhronosGroup/SPIRV-Cross/blob/5845e009ea25991264d1b848bea7e6d37469bdba/spirv_msl.cpp#L5593-L5609) that avoids emitting function constants? It looks like we could do either of these fallbacks:

• the default could be defined with a macro, which should also allow us to specialize SPIR-V into multiple MSL by prepending different macro values
• override the default and emit it directly

[MatthieuMv]

Hello, I was wondering if there is not a way to bypass this limit in 2023? This is very annoying for bindless texturing: it is required to specialize the hardware limit to access the full hardware potential.