<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 13, 2018 at 8:33 AM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com" target="_blank">emil.l.velikov@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 13 March 2018 at 15:02, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > On Tue, Mar 13, 2018 at 7:56 AM, Emil Velikov <<a href="mailto:emil.l.velikov@gmail.com">emil.l.velikov@gmail.com</a>> > wrote: >> >> On 12 March 2018 at 08:40, Iago Toral Quiroga <<a href="mailto:itoral@igalia.com">itoral@igalia.com</a>> wrote: >> > af5f2322d0c64 addressed this for extension commands, but the spec >> > mandates >> > this behavior also for core API commands. From the Vulkan spec, >> > Table 2. vkGetDeviceProcAddr behavior: >> > >> > device pname return >> > ---------------------------------------------------------- >> > (..) >> > device core device-level command fp >> > (...) >> > >> > See that it specifically states "device-level". >> > >> > Since the vk.xml file doesn't state if core commands are instance or >> > device level, we identify device level commands as the ones that take a >> > VkDevice, VkQueue or VkCommandBuffer as their first parameter. >> > >> > Fixes test failures in new work-in-progress CTS tests. >> > >> > Also see the public issue: >> > >> > <a href="https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/2323" rel="noreferrer" target="_blank">https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/2323</a> >> > >> > v2: >> > - Include reference to github issue (Emil) >> > - Rebased on top of Vulkan 1.1 changes. >> > >> > Reviewed-by: Emil Velikov <<a href="mailto:emil.velikov@collabora.com">emil.velikov@collabora.com</a>> (v1) >> > --- >> > >> > Emil, I had to rebase the patch on top of Jason's 1.1 changes. He had >> > already >> > accounted for device dispatches in that work, so now I just build on top >> > of >> > that now. With that, I am not sure whether the comment you were asking >> > for makes >> > sense in this patch any more (I think it should have gone in Jason's, >> > when he >> > added is_device_entrypoint()). I you want a comment for that I can send >> > another patch to include it, or maybe ammend the first patch in this >> > series to >> > include that. However, do notice that the comment you were referring to >> > has >> > been removed from the spec, since now it is clearly stated that only >> > core device-level commands return non-NULL pointers, so I think my >> > preference >> > would be to not add ny comments. >> > >> The suggestion was aimed as a reference, for anyone who missed the >> specific hunk in the spec update. >> There should be none, so yeah - don't bother ;-) >> >> > Also, this version won't do for 18.0, but I guess we can still use the >> > previous version for that if you want to put it in. >> > >> I would love to apply that one, if you don't mind. > > > I would rather we not back-port this to 18.0 at least not without > significant testing. From what I've heard from the WG, it looks lie the two > id games will be broken with it and the loader is not yet patched with a > work-around. > </div></div>Guess I have misunderstood Lenny's reply [1] - it indicated that Wolfenstein/Doom are fine with said change. </blockquote><div> </div><div>There have been what you might call "further developments". :-) </div></div></div></div>