Reverting the following patches: 1e41d7f7b0855934744fe578ba4eae9209ee69f7 - anv: Support loader interface version 3 (patch v2) 6d2fb04f0922047232d10b2a5d292d68c9506f45 - radv: radv: Support loader interface version 3. Fix Vulkan demos / vulkaninfo from coredumping on Haswell #1 0x00007ffff799d5d5 in terminator_CreateXcbSurfaceKHR () from /lib64/libvulkan.so.1 #2 0x0000000000467241 in VulkanSwapChain::initSurface(xcb_connection_t*, unsigned int) () #3 0x00000000004655bb in VulkanExampleBase::initSwapchain() ()
Would it be possible to get a stacktrace with debug symbols for libvulkan, as well as make sure it is somewhat up to date?
Issue sounds like a old libvulkan. We might be able to workaround that in the drivers, but the version used and a back trace (as mentioned by Bas) is needed.
Version is: vulkan-1.0.30.0-2.fc25.x86_64 Which is what Fedora 25 ships right now.
Skimming through the 30-37 commit log [1] I'm inclined to go with you _must_ update your vulkan loader. Older versions are broken in funny ways and attempting to workaround that in the ICD is a "crime". [1] https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/commits/master/loader/wsi.c
(In reply to Emil Velikov from comment #4) > Skimming through the 30-37 commit log [1] I'm inclined to go with you _must_ > update your vulkan loader. Older versions are broken in funny ways and > attempting to workaround that in the ICD is a "crime". I agree that people should be running up-to-date loaders. However, the Vulkan loader people shouldn't be allowed to break things either. The whole point of the loader is for it to be a rock-solid stable package that drivers can just assume is there.
I just ran vulkaninfo on my sky lake and it works just fine. I'm also running fedora 25, so I'm a bit confused. Can your environment get to your X display? I wonder if it's just failing to connect to X and the failure mode is to coredump.
Latest vulkaninfo from upstream git doesn't anymore coredump if DISPLAY is missing (some other programs do). However, it will still coredump if it cannot connect to the display server (e.g. when DISPLAY variable has wrong value).
Sorry, that was yesterday's git, in today's upstream git, vulkaninfo handles gracefully connection failures too.
(In reply to Eero Tamminen from comment #8) > Sorry, that was yesterday's git, in today's upstream git, vulkaninfo handles > gracefully connection failures too. That makes it sound a whole lot like it's a loader/vulkaninfo bug.
Things can be improved on Mesa side as well. Due to the difference in VKSurfaceKHR allocation [and related API] things can get rather nasty. All we need is to set a flag as vk_icdNegotiateLoaderICDInterfaceVersion is called, and if one calls vk_icdGetInstanceProcAddr with the flag off - we just bail ;-) Admittedly it's a bit pedantic check, but similar one is explicitly mentioned in the the the Negotiation API proposal [1] it would have caught/prevented this crash. I'll send a patch in a bit. [1] https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/180
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.