* [PATCH] radv: Allow physical device interfaces to be included in device extensions @ 2018-10-12 20:38 Keith Packard 2018-10-13 15:57 ` Bas Nieuwenhuizen 0 siblings, 1 reply; 8+ messages in thread From: Keith Packard @ 2018-10-12 20:38 UTC (permalink / raw) To: mesa-dev; +Cc: dri-devel 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. Signed-off-by: Keith Packard <keithp@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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-12 20:38 [PATCH] radv: Allow physical device interfaces to be included in device extensions Keith Packard @ 2018-10-13 15:57 ` Bas Nieuwenhuizen 2018-10-13 16:12 ` [Mesa-dev] " Jason Ekstrand 0 siblings, 1 reply; 8+ messages in thread From: Bas Nieuwenhuizen @ 2018-10-13 15:57 UTC (permalink / raw) To: Keith Packard; +Cc: mesa-dev, ML dri-devel On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@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. > Signed-off-by: Keith Packard <keithp@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-13 15:57 ` Bas Nieuwenhuizen @ 2018-10-13 16:12 ` Jason Ekstrand 2018-10-13 16:23 ` Bas Nieuwenhuizen 0 siblings, 1 reply; 8+ messages in thread From: Jason Ekstrand @ 2018-10-13 16:12 UTC (permalink / raw) To: Bas Nieuwenhuizen Cc: ML mesa-dev, Keith Packard, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 3083 bytes --] On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> wrote: > On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@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. :-( > > Signed-off-by: Keith Packard <keithp@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 > [-- Attachment #1.2: Type: text/html, Size: 4367 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-13 16:12 ` [Mesa-dev] " Jason Ekstrand @ 2018-10-13 16:23 ` Bas Nieuwenhuizen 2018-10-13 16:27 ` Jason Ekstrand 0 siblings, 1 reply; 8+ messages in thread From: Bas Nieuwenhuizen @ 2018-10-13 16:23 UTC (permalink / raw) To: Jason Ekstrand; +Cc: mesa-dev, ML dri-devel On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <jason@jlekstrand.net> wrote: > > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> wrote: >> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@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). > >> >> > Signed-off-by: Keith Packard <keithp@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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-13 16:23 ` Bas Nieuwenhuizen @ 2018-10-13 16:27 ` Jason Ekstrand 2018-10-13 17:36 ` Jason Ekstrand 0 siblings, 1 reply; 8+ messages in thread From: Jason Ekstrand @ 2018-10-13 16:27 UTC (permalink / raw) To: Bas Nieuwenhuizen; +Cc: ML mesa-dev, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 3927 bytes --] On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> wrote: > On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <jason@jlekstrand.net> > wrote: > > > > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen < > bas@basnieuwenhuizen.nl> wrote: > >> > >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@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 <keithp@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 > [-- Attachment #1.2: Type: text/html, Size: 5740 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-13 16:27 ` Jason Ekstrand @ 2018-10-13 17:36 ` Jason Ekstrand 2018-10-14 0:49 ` [Mesa-dev] " Keith Packard 0 siblings, 1 reply; 8+ messages in thread From: Jason Ekstrand @ 2018-10-13 17:36 UTC (permalink / raw) To: Bas Nieuwenhuizen; +Cc: ML mesa-dev, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 4222 bytes --] On Sat, Oct 13, 2018 at 11:27 AM Jason Ekstrand <jason@jlekstrand.net> wrote: > On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen < > bas@basnieuwenhuizen.nl> wrote: > >> On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <jason@jlekstrand.net> >> wrote: >> > >> > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen < >> bas@basnieuwenhuizen.nl> wrote: >> >> >> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@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@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 >> > [-- Attachment #1.2: Type: text/html, Size: 6395 bytes --] [-- Attachment #2: Type: text/plain, Size: 157 bytes --] _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-13 17:36 ` Jason Ekstrand @ 2018-10-14 0:49 ` Keith Packard 2018-10-14 2:11 ` Jason Ekstrand 0 siblings, 1 reply; 8+ messages in thread From: Keith Packard @ 2018-10-14 0:49 UTC (permalink / raw) To: Jason Ekstrand, Bas Nieuwenhuizen Cc: ML mesa-dev, Maling list - DRI developers [-- Attachment #1.1: Type: text/plain, Size: 367 bytes --] Jason Ekstrand <jason@jlekstrand.net> writes: > Actually, I think anv is doing the right thing too. Now I have no idea why > Keith was having problems. anv is happily returning a valid pointer and radv is not? In any case, I've switched to using vkGetInstanceProcAddr for the VkPhysicalDevice function and it works fine with both drivers. -- -keith [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] [-- Attachment #2: Type: text/plain, Size: 160 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Mesa-dev] [PATCH] radv: Allow physical device interfaces to be included in device extensions 2018-10-14 0:49 ` [Mesa-dev] " Keith Packard @ 2018-10-14 2:11 ` Jason Ekstrand 0 siblings, 0 replies; 8+ messages in thread From: Jason Ekstrand @ 2018-10-14 2:11 UTC (permalink / raw) To: Keith Packard, Bas Nieuwenhuizen Cc: ML mesa-dev, Maling list - DRI developers On October 13, 2018 19:50:00 "Keith Packard" <keithp@keithp.com> wrote: > Jason Ekstrand <jason@jlekstrand.net> writes: > >> Actually, I think anv is doing the right thing too. Now I have no idea why >> Keith was having problems. > > anv is happily returning a valid pointer and radv is not? > > In any case, I've switched to using vkGetInstanceProcAddr for the > VkPhysicalDevice function and it works fine with both drivers. Using vkGetInstanceProcAddr is the right thing to do. The fact that anv allows you to is a bug which should be investigated and fixed. I looked at it a bit today and I'm still not sure how it's happening. --Jason _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-10-14 2:11 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-10-12 20:38 [PATCH] radv: Allow physical device interfaces to be included in device extensions Keith Packard 2018-10-13 15:57 ` Bas Nieuwenhuizen 2018-10-13 16:12 ` [Mesa-dev] " Jason Ekstrand 2018-10-13 16:23 ` Bas Nieuwenhuizen 2018-10-13 16:27 ` Jason Ekstrand 2018-10-13 17:36 ` Jason Ekstrand 2018-10-14 0:49 ` [Mesa-dev] " Keith Packard 2018-10-14 2:11 ` Jason Ekstrand
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.