On Tue, 2018-03-06 at 11:21 +0000, Emil Velikov wrote: > On 6 March 2018 at 09:57, Bas Nieuwenhuizen <ba...@chromium.org> > wrote: > > > > > > On Tue, Mar 6, 2018 at 8:02 AM, Iago Toral <ito...@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."
Because it is not using the pointers :), if some other app is using them it will start to crash. But that was not my point, my point was that this doesn't fix anything for users, so I was questioning whether it was material for stable based on that. > > > > > 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. > > HTH > Emil > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
