Makes sense. Although presumably that doesn't mean we have to upload them that way—I was envisioning solving that particular problem by copying both external and internal constants into a temp array in the compiled shader. (But maybe that's more overhead for the lower level compiler?)
I imagine it would be slower, yes. In part because relative addressing typically means all constants are potentially accessed instead of the more limited set typically used by applications. So we'd introduce a bunch of loads from the UBO/CBV that may never end up actually being used.
I guess you're trying to avoid having to use vkd3d_shader_scan() to determine the values of "local" constants? It would be nice if we could, but there may not be a good solution for that.
I think I see what you're trying to get at. I've rewritten this bit in v2; does this seem more reasonable?
Yeah, that works for me.
+ for (i = 0; i < ARRAY_SIZE(parser->shader_desc.flat_constant_count); ++i) + { + struct vkd3d_shader_register_range range = {.space = 0, .first = i, .last = i}; + + if (parser->shader_desc.flat_constant_count[i].external) + vkd3d_shader_scan_add_descriptor(&context, VKD3D_SHADER_DESCRIPTOR_TYPE_CBV, + &range, VKD3D_SHADER_RESOURCE_BUFFER, VKD3D_SHADER_RESOURCE_DATA_FLOAT, 0); + }
It's fairly minor, but I'd still feel better about this if it used VKD3D_SHADER_RESOURCE_DATA_UINT. Or perhaps we can use a common helper shared with vkd3d_shader_scan_constant_buffer_declaration().