Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
color_space_helper: Allow all texture formats for the sRGB color space
Most texture formats should be presentable on the default sRGB color space, in particular 10-bit formats for higher bit depth and detail than the typical 8-bit. A couple notes: - This currently only affects `VK_KHR_display` as there is a `needsWorkaround` case in `PhysicalDevice::GetSurfaceFormats()` that returns exclusively RGBA8 and BGRA8 in the windowed/compositor case; - Before this patch, `A2B10G10R10` wasn't in the list returned by `vkGetPhysicalDeviceSurfaceFormatsKHR()` but worked anyway on `VK_KHR_display` _without_ validation errors; - Using the `A2B10G10R10` format inside a 10-bit compositor works anyway, albeit with validation layer errors; - RADV also allows 10-bit sRGB swapchains, but only in a compositor, not in `VK_KHR_display`; - Windows also does not report support for this 10-bit sRGB format combination, but it works anyway (also with validation layer errors); - By using `Fmt_All`, the `R16G16B16A16_UNORM` and `R16G16B16A16_SFLOAT` formats become available for the sRGB color space, but creating a swapchain with them leaves a black screen. If this is truly unsupported, perhaps there should be a new `Fmt_8bpc_10bpc`? - This was previously `Fmt_All` already before commit 02e867e ("Update xgl from commit 2aeb0b25") but it is assumed that sub-commit "Fix ColorspaceHelper's lookup table so it only reports formats that are legal" changed this behaviour. At least 10-bit sRGB should be retained? (When saying "it works", I mean that it works as intended, i.e. any 8-bit banding previously observable is gone when using a 10-bit swapchain)
- Loading branch information