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
