On Thu, 25 Nov 2021 at 04:32, Conor McCarthy cmccarthy@codeweavers.com wrote:
November 25, 2021 4:36 AM, "Henri Verbeet" hverbeet@gmail.com wrote:
In the case of descriptor offsets, what's missing is support for specifying arrays. That may simply be a matter of adding something like "const uint32_t *u32_array;" to the union in the vkd3d_shader_parameter_immediate_constant structure. The specialisation constant path should work fine as-is in terms of API, but probably needs some work in terms of SPIR-V generation.
Should this use a new helper for getting an immediate constant from an array, something like:
vkd3d_dxbc_compiler_get_uint_shader_array_parameter(struct vkd3d_dxbc_compiler *compiler, enum vkd3d_shader_parameter_name name, unsigned int index)Plus a data type check in vkd3d_dxbc_compiler_emit_uint_shader_parameter().
Something along those lines. I think vkd3d_dxbc_compiler_get_constant_uint() should work fine for arrays, the caller can just pass something like "parameter->u.immediate_constant.u.u32_array[index]". We'd want an indexed variant of vkd3d_dxbc_compiler_emit_uint_shader_parameter() though, which we could then use in vkd3d_dxbc_compiler_get_descriptor_index().
I don't see a need to support specialisation constant arrays. We can just emit a compiler error if the UINT32_ARRAY data type is specified for a specialisation constant.
We could, but it's weird in terms of API consistency. From the point of view of a user of the API, there doesn't seem to be a good reason specialisation constant arrays wouldn't/shouldn't/couldn't be supported. It doesn't seem terribly hard to add either.