On 6/4/20 3:48 PM, Henri Verbeet wrote:
On Thu, 4 Jun 2020 at 06:20, Zebediah Figura zfigura@codeweavers.com wrote:
+struct vkd3d_uav_scan_info +{
- unsigned int register_space, register_index, id;
- bool counter, read;
+};
It seems tempting to store the "counter" and "read" fields as a "flags" field instead. For what it's worth, note that I also have patches in this area in my own tree; we'll need to store information about the other descriptor types in the vkd3d_shader_scan_info at some point as well.
Sure, that makes sense.
I'm not sure whether there's a use for the "id" field in the public API. I'm inclined to say lookup by ID should go through the "symbol_table" tree.
Yes, I don't see a reason to expose "id".
Is the idea then to introduce a new symbol table in struct vkd3d_shader_parser? It seems a bit unfortunate that the table would be duplicated, but after all I guess it's not a lot of duplication...
Perhaps more important is the question how this would work with ranges larger than a single descriptor. I.e., how would for example a "dcl_uav_raw u0[1:3], ..." declaration be represented in the vkd3d_shader_scan_info structure?
It's hard for me to answer that without a full perspective as to how the indices are or might be used, but my best guess is that, if descriptor ranges are uploaded all at once, we'd want to track a single used/counter flag for the whole range.