search

SaschaWillems / VulkanCapsViewer

Vulkan hardware capability viewer
GNU Lesser General Public License v3.0
319 stars 70 forks source link

Supported formats and features differ between web interface and application #174

Closed Sonicadvance1 closed 1 year ago

Sonicadvance1 commented 1 year ago

This seems like an issue on the application side where it is generating a report incorrectly, but I'm not overly familiar with the json format to validate this 100%.

This is showing up on an ARM64 Linux device, but has also been confirmed to be an issue on an Android device as well.

This json report was generated with VulkanCapsViewer git hash bf81c3dac833d53dc9137978c5d92549619217d5: https://gist.github.com/Sonicadvance1/7ef7a9eec77c4989644e7b398b918008 (Github is super cool and doesn't allow json file attachments on issues) The web format report is here: https://vulkan.gpuinfo.org/displayreport.php?id=19938#formats_optimal

The application shows the supported formats with the expected tiling and buffer flags, where the website isn't showing this at all.

This can be seen by looking at the A1R5G5B5_UNORM_PACK16 format at the top of the list theoretically only supporting UNIFORM_TEXEL_BUFFER for buffer flags, but if we look at the screenshot from the application, it supports significantly more. Screenshot 2023-03-28 15-35-12

This isn't just related to the top-most format of course, all uncompressed formats seem to be missing from the list when viewed on the website.

If you need any more information then let me know. This was very confusing when passing the report around and noticing a bunch of missing uncompressed formats.

https://github.com/SaschaWillems/vulkan.gpuinfo.org/issues/50 Might be a related issue?

Sonicadvance1 commented 1 year ago

This is a mesa bug https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/vulkan/runtime/vk_physical_device.c#L193 This fails to sanitize correctly from FORMAT_PROPERTIES_2 to original VkPhysicalDevice properties uint32_t typedef. The Maximum VkPhysicalDevice value is 0x7FFF'FFFF, but VK_FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT sets bit 31. So with it failing to sanitize that bit, it gets passed through, freaking vulkancapsviewer out since when exporting to json it uses an int type, which is fine for the original format expectations.

Alternatively VulkanCapsViewer could grow support for vkGetPhysicalDeviceProperties2 and consuming the bit flags as a 64-bit value.