Summary: | segfault when calling vkGetPhysicalDeviceFormatProperties with VK_FORMAT_PVRTC1_2BPP_UNORM_BLOCK_IMG | ||
---|---|---|---|
Product: | Mesa | Reporter: | Mike Schuchardt <mikes> |
Component: | Drivers/Vulkan/intel | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Status: | RESOLVED NOTABUG | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
Severity: | normal | ||
Priority: | medium | CC: | jason |
Version: | 17.1 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | Patch to try |
Description
Mike Schuchardt
2017-07-27 20:10:14 UTC
Created attachment 133083 [details] [review] Patch to try Is it even valid to pass VK_FORMAT_PVRT1_2BPP_UNORM_BLOCK_IMG into the driver if it doesn't support the relevant extension? I guess if it's a device extension, we wouldn't be able to rely on that for a PhysicalDevice query. I've attached a driver patch that should make us handle it correctly anyway. Mind giving it a try? This patch fixes the reported issue. After more consideration I'm not sure this is a valid use case because of the documented interaction between physical-device-level extension functionality and device extensions. From the spec 31.2.1, last paragraph: In order to avoid using an instance extension, which often requires loader support, the VK_KHR_get_physical_device_properties2 extension allows physical-device-level extension functionality to be implemented within device extensions (which must depend on the VK_KHR_get_physical_device_properties2 extension). It is further muddled by the fact that VK_IMG_format_pvrtc predates VK_KHR_get_physical_device_properties2, but I believe the intent is the same. |
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.