<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Oct 13, 2018 at 11:27 AM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Oct 13, 2018 at 11:24 AM Bas Nieuwenhuizen <<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank">bas@basnieuwenhuizen.nl</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Oct 13, 2018 at 6:12 PM Jason Ekstrand <<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>> wrote:<br> ><br> > On Sat, Oct 13, 2018 at 10:58 AM Bas Nieuwenhuizen <<a href="mailto:bas@basnieuwenhuizen.nl" target="_blank">bas@basnieuwenhuizen.nl</a>> wrote:<br> >><br> >> On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <<a href="mailto:keithp@keithp.com" target="_blank">keithp@keithp.com</a>> wrote:<br> >> ><br> >> > According to the Vulkan spec:<br> >> ><br> >> > "Vulkan 1.0 initially required all new physical-device-level extension<br> >> > functionality to be structured within an instance extension. In order<br> >> > to avoid using an instance extension, which often requires loader<br> >> > support, physical-device-level extension functionality may be<br> >> > implemented within device extensions"<br> >> ><br> >> > The code that checks for enabled extension APIs currently only passes<br> >> > functions with VkDevice or VkCommandBuffer as their first<br> >> > argument. This patch extends that to also allow functions with<br> >> > VkPhysicalDevice parameters, in support of the above quote from the<br> >> > Vulkan spec.<br> >> ><br> >><br> >> Also "To obtain a function pointer for a physical-device-level command<br> >> from a device extension, an application can use vkGetInstanceProcAddr.<br> >> "<br> >><br> >> As far as I can tell the device_command member is only to make sure we<br> >> return NULL from vkGetDeviceProcAddr, and per the spec (3.1 table 2)<br> >> we still have to return NULL there for functions which take<br> >> VkPhysicalDevice? So the old behavior seems correct to me.<br> ><br> ><br> > 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...<br> ><br> > 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. :-(<br> <br> How would you read that into the spec? As quoted above it explicitly<br> tells you to use vkGetInstanceProcAddr for VkPhysicalDevice functions,<br> even if they are based on a device extension. (And you cannot really<br> use vkGetDeviceProcAddr anyway as the typical usecase is before you've<br> created a device).<br></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>Actually, I think anv is doing the right thing too. Now I have no idea why Keith was having problems.</div><div><br></div><div>--Jason</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> ><br> >><br> >> > Signed-off-by: Keith Packard <<a href="mailto:keithp@keithp.com" target="_blank">keithp@keithp.com</a>><br> >> > ---<br> >> > src/amd/vulkan/radv_entrypoints_gen.py | 2 +-<br> >> > 1 file changed, 1 insertion(+), 1 deletion(-)<br> >> ><br> >> > diff --git a/src/amd/vulkan/radv_entrypoints_gen.py b/src/amd/vulkan/radv_entrypoints_gen.py<br> >> > index 377b544c2aa..69e6fc3e0eb 100644<br> >> > --- a/src/amd/vulkan/radv_entrypoints_gen.py<br> >> > +++ b/src/amd/vulkan/radv_entrypoints_gen.py<br> >> > @@ -352,7 +352,7 @@ class Entrypoint(EntrypointBase):<br> >> > self.return_type = return_type<br> >> > self.params = params<br> >> > self.guard = guard<br> >> > - self.device_command = len(params) > 0 and (params[0].type == 'VkDevice' or params[0].type == 'VkQueue' or params[0].type == 'VkCommandBuffer')<br> >> > + 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')<br> >> ><br> >> > def prefixed_name(self, prefix):<br> >> > assert self.name.startswith('vk')<br> >> > --<br> >> > 2.19.1<br> >> ><br> >> > _______________________________________________<br> >> > mesa-dev mailing list<br> >> > <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br> >> > <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> >> _______________________________________________<br> >> mesa-dev mailing list<br> >> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br> >> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> </blockquote></div></div> </blockquote></div></div>