[Mesa-dev] [PATCH] anv: Implement VK_KHR_get_physical_device_properties2

[Chad Versace]

On Mon 23 Jan 2017, Jason Ekstrand wrote:
> On Mon, Jan 23, 2017 at 3:31 PM, Chad Versace <chadversary at chromium.org> wrote:
> 
>     On Mon 23 Jan 2017, Jason Ekstrand wrote:
>     > On Mon, Jan 23, 2017 at 2:28 PM, Chad Versace <chadversary at chromium.org>
>     wrote:
>     >
>     >     Implement each vkFoo2KHR() by trivially passing it through to the
>     >     original vkFoo().
>     >
>     >
>     > As I mentioned to Lionel when he wrote basically this exact same patch, I
>     think
>     > that may be backwards.  I can see two ways of doing this long-term:
> 
>     If we look into the future, my patch is indeed backwards.
>     >
>     > 1) Implement all of the queries (of a particular type) in a single
>     function and
>     > the legacy query calls the query2 variant and then copies the data over.
> 
>     Option 1 is definitely better than my patch.
>    
>     > 2) Implement each query as its own function and the queries2 function
>     loops
>     > over the data structures calling the appropriate function on each one.
> 
>     I don't see exactly what you're proposing in option 2. Do you mean, for
>     example,
>     that vkGetPhysicalDeviceFormatProperties2KHR() would, for each structure
>     chained off of the input and output structs, including the toplevel
>     structs themselves, call some function specific to those structs?
> 
> 
> I mean it would be
> 
> for (struct_base *s = pPhysicalDeviceProperties; s; s = s->pNext) {
>    switch (s->type) {
>    case VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_PROPERTIES2: {
>       VkPhysicalDeviceProperties2 *props = s;
>       anv_GetPhysicalDeviceProperties(pdev, &props->props);
>       break;
>    case VK_STRUCTURE_TYPE_SOMETHING_ELSE:
>       VkSomethingElse *thing = s;
>       anv_get_something_else(pdev, thing);
>       break;
>    ...
>    default:
>       assert(!"Invalid structure type");
>    }
> }

All vkGetFoo2KHR() funcs have output structs; only a subset have input
structs. Therefore, if we choose to do option 2, for uniformity's sake
we should implement it by iterating over the output structs, even when
input structs are present. 

What do you think?

Also, about that assertion in the default case... I believe drivers are
required to ignore unrecongized extension structs. From the Vulkan
1.0.38 spec:

   Any component of the implementation (the loader, any enabled layers,
   and drivers) must skip over, without processing (other than reading the
   sType and pNext members) any chained structures with sType values not
   defined by extensions supported by that component.