[Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions

[Jason Ekstrand]

On Sat, Oct 13, 2018 at 11:27 AM Jason Ekstrand <jason at jlekstrand.net>
wrote:

> On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen <
> bas at basnieuwenhuizen.nl> wrote:
>
>> On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <jason at jlekstrand.net>
>> wrote:
>> >
>> > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <
>> bas at basnieuwenhuizen.nl> wrote:
>> >>
>> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp at 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.
>

Actually, I think anv is doing the right thing too.  Now I have no idea why
Keith was having problems.

--Jason



>
>
>> >
>> >>
>> >> > Signed-off-by: Keith Packard <keithp at 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 at lists.freedesktop.org
>> >> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>> >> _______________________________________________
>> >> mesa-dev mailing list
>> >> mesa-dev at lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181013/dc9af599/attachment-0001.html>