On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <[email protected]> wrote: > > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <[email protected]> > wrote: >> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <[email protected]> wrote: >> > >> > According to the Vulkan spec: >> > >> > "Vulkan 1.0 initially required all new physical-device-level extension >> > functionality to be structured within an instance extension. In order >> > to avoid using an instance extension, which often requires loader >> > support, physical-device-level extension functionality may be >> > implemented within device extensions" >> > >> > The code that checks for enabled extension APIs currently only passes >> > functions with VkDevice or VkCommandBuffer as their first >> > argument. This patch extends that to also allow functions with >> > VkPhysicalDevice parameters, in support of the above quote from the >> > Vulkan spec. >> > >> >> Also "To obtain a function pointer for a physical-device-level command >> from a device extension, an application can use vkGetInstanceProcAddr. >> " >> >> As far as I can tell the device_command member is only to make sure we >> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2) >> we still have to return NULL there for functions which take >> VkPhysicalDevice? So the old behavior seems correct to me. > > > I think anv is ignoring that line in the table which is why it works for us. > If only someone wrote tests for these things... > > I think the correct interpretation would be that any physical device > functions that are part of a core version or instance extension should yield > NULL but any physical device functions from a device extension should return > a valid function pointer. Sadly, that behavior is kind-of a pain to > implement. :-(
How would you read that into the spec? As quoted above it explicitly tells you to use vkGetInstanceProcAddr for VkPhysicalDevice functions, even if they are based on a device extension. (And you cannot really use vkGetDeviceProcAddr anyway as the typical usecase is before you've created a device). > >> >> > Signed-off-by: Keith Packard <[email protected]> >> > --- >> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py >> > b/src/amd/vulkan/radv_entrypoints_gen.py >> > index 377b544c2aa..69e6fc3e0eb 100644 >> > --- a/src/amd/vulkan/radv_entrypoints_gen.py >> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py >> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase): >> > self.return_type = return_type >> > self.params = params >> > self.guard = guard >> > - self.device_command = len(params) > 0 and (params[0].type == >> > 'VkDevice' or params[0].type == 'VkQueue' or params[0].type == >> > 'VkCommandBuffer') >> > + self.device_command = len(params) > 0 and (params[0].type == >> > 'VkPhysicalDevice' or params[0].type == 'VkDevice' or params[0].type == >> > 'VkQueue' or params[0].type == 'VkCommandBuffer') >> > >> > def prefixed_name(self, prefix): >> > assert self.name.startswith('vk') >> > -- >> > 2.19.1 >> > >> > _______________________________________________ >> > mesa-dev mailing list >> > [email protected] >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev >> _______________________________________________ >> mesa-dev mailing list >> [email protected] >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
