* [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.