On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl> wrote:
> On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <ja...@jlekstrand.net> > wrote: > > > > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen < > b...@basnieuwenhuizen.nl> wrote: > >> > >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <kei...@keithp.com> > 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). > Because I was reading the wrong chunk of spec. :-( You are correct and radv is like doing the right thing and anv is doing the wrong thing. --Jason > > > >> > >> > Signed-off-by: Keith Packard <kei...@keithp.com> > >> > --- > >> > 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 > >> > mesa-dev@lists.freedesktop.org > >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > >> _______________________________________________ > >> mesa-dev mailing list > >> mesa-dev@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev