vkd3d-shader: Implement scanning combined resource/sampler information.
Merge request reports
Activity
861 870 &semantic->resource.range, semantic->resource_type, VKD3D_SHADER_RESOURCE_DATA_FLOAT); 862 871 } 863 872 873 static void vkd3d_shader_scan_combined_sampler_usage(struct vkd3d_shader_scan_context *context, 874 const struct vkd3d_shader_register *resource, const struct vkd3d_shader_register *sampler) 875 { 876 struct vkd3d_shader_scan_combined_resource_sampler_info *info; 877 struct vkd3d_shader_combined_resource_sampler_info *s; 878 unsigned resource_space = 0, sampler_space = 0; 879 unsigned int resource_idx, sampler_idx, i; 880 881 if (!(info = context->combined_sampler_info)) 882 return; 883 884 if (resource->type == VKD3DSPR_RESOURCE) What could this be other than a resource register? And similarly for the sampler?
For d3dbc sources, either VKD3DSPR_COMBINED_SAMPLER, or VKD3DSPR_TEXTURE before SM2. We may want to consider running this after normalise_combined_samplers() in the future, but at least for the moment that doesn't handle all texture instructions and shader models.
I'm currently out and haven't had a chance to properly look at this, but, how does this interact with resource arrays?
Resource arrays should work as long as they're not dynamically indexed. (And the ps_5_1 test exercises that path.) Dynamic indexing of resource arrays can't work with combined samplers; there's essentially no way to create the required combined samplers in either the OpenGL or Vulkan APIs, and it's not clear what that would even look like.
There's perhaps an unresolved question of how to handle that if we do run into it in the scanner. The current behaviour is to return the base index for such accesses; an argument could be made for either not recording them at all, or e.g. setting some flag in the vkd3d_shader_combined_resource_sampler_info structure to indicate dynamic indexing is involved. Ultimately such shaders just aren't going to be usable with combined samplers though.