On Fri, Oct 12, 2018 at 10:38 PM Keith Packard <keithp@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
