[Mesa-stable] [Mesa-dev] [PATCH] anv/entrypoints: VkGetDeviceProcAddr returns NULL for core instance commands

Emil Velikov emil.l.velikov at gmail.com
Tue Mar 6 11:21:48 UTC 2018

On 6 March 2018 at 09:57, Bas Nieuwenhuizen <basni at chromium.org> wrote:
> On Tue, Mar 6, 2018 at 8:02 AM, Iago Toral <itoral at igalia.com> wrote:
>> On Mon, 2018-03-05 at 12:11 +0000, Emil Velikov wrote:
>> > Hi Iago,
>> >
>> > Top level questions:
>> >
>> > I think this and the original commit should go to stable right?
>> I am not sure if this qualifies for stable: these patches don't fix any
>> user-visible bugs. If an application was calling vkGetDeviceProcAddr to
>> get pointers to non-device functions (which is incorrect by the spec)
>> the previous behavior would allow it to get away with it without
>> issues, bit with these patches it will start to crash since it will
>> receive NULL pointers.
According to Lenny's comment in the github issue there's nothing to be
concerned. Namely:
 - "The pointers being returned are invalid. ... trying to use them
will result in a crash."
 - "Wolfenstein was acquiring, but not using the pointers."

>> > The dispatch in 17.3 is very different making, yet 18.0 should be
>> > perfectly fine.
>> >
>> > Mildly related - anv is missing a special case for following three
>> > extensions. Should we port those over from radv?
>> >
>> > vkCreateInstance vkEnumerateInstanceExtensionProperties
>> > vkEnumerateInstanceLayerProperties
>> What is the exception exactly? Right now we report NULL for these from
>> vkGetDeviceProcAddr which is the right thing to do.
> He's talking about the 3 instance commands that we should return in the
> GetInstanceProcAddr even if instance is NULL, but anv handles that inside
> anv_device.c anyway, so I don't think there is anything to be done there.

Indeed. Thanks Bas.


More information about the mesa-stable mailing list