<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 24/01/17 00:50, Jason Ekstrand
wrote:<br>
</div>
<blockquote
cite="mid:CAOFGe94MpHY61fc-jWETz1wSfEaz-z-wACt+L8C+7BpArc-GOA@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<br>
What do you think about
<a class="moz-txt-link-freetext" href="https://patchwork.freedesktop.org/patch/134841/">https://patchwork.freedesktop.org/patch/134841/</a> ?<br>
Is that close enough to what you have in mind?<br>
<br>
Thanks,<br>
<br>
-<br>
Lionel<br>
</body>
</html>