<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 23, 2017 at 4:25 PM, Chad Versace <span dir="ltr"><<a href="mailto:chadversary@chromium.org" target="_blank">chadversary@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon 23 Jan 2017, Jason Ekstrand wrote:<br>
> On Mon, Jan 23, 2017 at 3:31 PM, Chad Versace <<a href="mailto:chadversary@chromium.org">chadversary@chromium.org</a>> wrote:<br>
><br>
>     On Mon 23 Jan 2017, Jason Ekstrand wrote:<br>
>     > On Mon, Jan 23, 2017 at 2:28 PM, Chad Versace <<a href="mailto:chadversary@chromium.org">chadversary@chromium.org</a>><br>
>     wrote:<br>
>     ><br>
>     >     Implement each vkFoo2KHR() by trivially passing it through to the<br>
>     >     original vkFoo().<br>
>     ><br>
>     ><br>
>     > As I mentioned to Lionel when he wrote basically this exact same patch, I<br>
>     think<br>
>     > that may be backwards.  I can see two ways of doing this long-term:<br>
><br>
>     If we look into the future, my patch is indeed backwards.<br>
>     ><br>
>     > 1) Implement all of the queries (of a particular type) in a single<br>
>     function and<br>
>     > the legacy query calls the query2 variant and then copies the data over.<br>
><br>
>     Option 1 is definitely better than my patch.<br>
><br>
>     > 2) Implement each query as its own function and the queries2 function<br>
>     loops<br>
>     > over the data structures calling the appropriate function on each one.<br>
><br>
>     I don't see exactly what you're proposing in option 2. Do you mean, for<br>
>     example,<br>
>     that vkGetPhysicalDeviceFormatPrope<wbr>rties2KHR() would, for each structure<br>
>     chained off of the input and output structs, including the toplevel<br>
>     structs themselves, call some function specific to those structs?<br>
><br>
><br>
> I mean it would be<br>
><br>
> for (struct_base *s = pPhysicalDeviceProperties; s; s = s->pNext) {<br>
>    switch (s->type) {<br>
>    case VK_STRUCTURE_TYPE_PHYSICAL_<wbr>DEVICE_PROPERTIES2: {<br>
>       VkPhysicalDeviceProperties2 *props = s;<br>
>       anv_<wbr>GetPhysicalDeviceProperties(<wbr>pdev, &props->props);<br>
>       break;<br>
>    case VK_STRUCTURE_TYPE_SOMETHING_<wbr>ELSE:<br>
>       VkSomethingElse *thing = s;<br>
>       anv_get_something_else(pdev, thing);<br>
>       break;<br>
>    ...<br>
>    default:<br>
>       assert(!"Invalid structure type");<br>
>    }<br>
> }<br>
<br>
</div></div>All vkGetFoo2KHR() funcs have output structs; only a subset have input<br>
structs. Therefore, if we choose to do option 2, for uniformity's sake<br>
we should implement it by iterating over the output structs, even when<br>
input structs are present.<br>
<br>
What do you think?<br></blockquote><div><br></div><div>You bring up an interesting point.  I'm wondering if we don't want to do the helper thing and also pass the query info struct to all of the helpers.  If they want to pull information out of chained children, it's their job to crawl through and find them.  Otherwise, we would have to come up with some sort of weird double-iterator and I can't imagine that ending well.<br><br></div><div>The more I think about this, the more convinced I become that we want a helper per chaining query so maybe your patch is actually ok modulo adding some for loops when it comes time to extend one of the queries.  I think I'd be a fan of adding the for loops now though.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, about that assertion in the default case... I believe drivers are<br>
required to ignore unrecongized extension structs. From the Vulkan<br>
1.0.38 spec:<br>
<br>
   Any component of the implementation (the loader, any enabled layers,<br>
   and drivers) must skip over, without processing (other than reading the<br>
   sType and pNext members) any chained structures with sType values not<br>
   defined by extensions supported by that component.<br>
</blockquote></div><br></div><div class="gmail_extra">Right...<br></div></div>