On Fri, 5 Jun 2020 at 01:39, Zebediah Figura zfigura@codeweavers.com wrote:
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...
No, the idea would be that in spirv.c you'd use the symbol table to lookup the range information for the ID, and then use that information to lookup the counter/read information. E.g.:
dcl_uav_typed u0[1:3], ..., space=4 ... store_uav_typed u0[1], ...
The store_uav_typed handler would lookup u0 in the symbol table and find that it corresponds to [1:3] in register space 4. Index 1 in that range would then be descriptor 2 in that register space 4. It would then lookup the information for descriptor 2 in register space 4 in the vkd3d_shader_scan_info to check whether that's a readonly UAV. (There are of course variants on that, like doing the lookup when inserting u0 in the symbol table, etc. To some extent it also depends on what we do with the issue below.)
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.
It probably needs tests to determine whether it's allowed in practice, but the bytecode seems to allow for overlapping ranges. E.g.:
dcl_uav_raw u0[1:4], ..., space=0 dcl_uav_raw u1[3:6], ..., space=0
would make both u0[2] and u1[0] refer to descriptor 3 in register space 0. But even without aliasing, it's not clear to me that e.g. using the counter for u0[0] necessarily implies that all of u0 needs one.