Add VK_EXT_swapchain_colorspace2

[llyyr]

Follow-up from #2648

Primary motivation for this is Wayland platform, which recommends to use gamma2.2 for video and computer graphics for applications but there's no gamma2.2 colorspace to set via the Vulkan API.

Driver implementation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39152
Client implementation: https://code.videolan.org/videolan/libplacebo/-/merge_requests/775

[Headcrabed]

I have two advices:

1. add sRGB to colorspace name to keep together with existing colorspaces.(Also we need that to mark it has sRGB primaries)
2. add more color primaries for 2.2, for example DCI-P3 D65 and BT.2020.

[llyyr]

I have two advices:

I've been told Khronos SI group have been looking into this internally as well, so this extension may not make it in. Besides this, it'd be also nice to resolve EXTENDED_SRGB_LINEAR_EXT in this extension. See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12689

It may be easier to submit this as a VK_MESA extension to ship this faster, which would then be superseded by whatever solution Khronos group comes up with.

I can't see a way to cleanly do this without deprecating the SRGB enum because it's definition is so overloaded and can mean both sRGB piecewse transfer and gamma2.2 transfer at the same time. Introducing an explicit sRGB piecewise enum would be best

[Headcrabed]

I can't see a way to cleanly do this without deprecating the SRGB enum because it's definition is so overloaded and can mean both sRGB piecewse transfer and gamma2.2 transfer at the same time. Introducing an explicit sRGB piecewise enum would be best

I think naming as something like VK_COLOR_SPACE_SRGB_POWER22_EXT or VK_COLOR_SPACE_SRGB_POWER22_NONLINEAR_EXT is ok?

[cubanismo]

Thanks for working on this @llyyr. We discussed at Khronos today, and wanted to note that yes, we are discussing the EXTENDED_SRGB color space issues as well, and we could indeed resolve those in the same spec if you're willing to wait for the solution to be worked out there. If you'd prefer to ship an interim MESA spec, that would of course be fine as well.

Since there's some debate here over how to position this new color space relative to the existing sRGB color spaces, I'd also like to note that one solution under consideration for the scRGB issue is updating the spec to note the disparities in behavior of current implementations, and add two (or more) new color space enums that strictly define the alternate implementation behaviors. Each platform would advertise the existing, now loosely-defined color space, as well as one of the new more precisely-defined color space enums. This would allow applications aware of the new extension to opt-in to receiving more precisely defined color spaces, and existing applications would continue to work and behave however they do now.

It sounds like a similar solution could be applied to the sRGB color spaces, since it sounds like there are similar concerns about divergent interpretations of the existing enum in current implementations. You could add both POWER22 and PIECEWISE, for example, sRGB color space enums, and reword the existing color space description to say it may refer to either of those color spaces depending on the implementation (I.e., platform-defined behavior/variance).

[llyyr]

That sounds perfect! I don't mind waiting for the Khronos. Though I'll see if there's interest in having an interim MESA spec and pursue that if there is.

Another thing I wanted to tackle in the future is exposing a way for applications using VK_EXT_hdr_metadata to be able to set the primaries and luminance they're targeting. Currently there's only provision to set the mastering display metadata which isn't sufficient on all platforms. Is this also something that's being discussed internally? If not, what would be the ideal way to pursue this change (as a new extension or addition to VK_EXT_hdr_metadata)?