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 8- and 10-bit fmts for the sRGB color space (…
…#175) * color_space_helper: Allow 8- and 10-bit fmts 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); - 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) * color_space_helper: Split out 10bpc format in unorm and srgb
- Loading branch information