From: Zebediah Figura Subject: Re: [PATCH vkd3d 4/5] vkd3d-shader: Return the register space of each used UAV and UAV counter in vkd3d_shader_scan_info. Message-Id: Date: Thu, 4 Jun 2020 16:09:47 -0500 In-Reply-To: References: <20200604014915.986832-1-zfigura@codeweavers.com> <20200604014915.986832-4-zfigura@codeweavers.com> On 6/4/20 3:48 PM, Henri Verbeet wrote: > On Thu, 4 Jun 2020 at 06:20, Zebediah Figura 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.