Future proof transferFunction restrictions.

[MarkCallow]

@lexaknyazev please review. I want to give direction for how the transferFunction for possible new formats should be handled as the spec already says that formats added to the Vulkan spec. in future can be used.

[lexaknyazev]

LGTM. Please also update the line 880 to allow KHR_DF_MODEL_YUVSDA, since the spec allows YUV formats in general.

[MarkCallow]

LGTM. Please also update the line 880 to allow KHR_DF_MODEL_YUVSDA, since the spec allows YUV formats in general.

Happy to do it but under what circumstances should this be allowed? All the Vulkan formats appear to be RGB.

[lexaknyazev]

Although they are called RGB, some of them require a sampler Y′C_BC_R conversion as stated here. The conversion may be a no-op (RGB identity), so both RGB and YUV models should be allowed for those formats.

Filtering the current KTX format list, a sampler Y′C_BC_R conversion is required for

• all non-prohibited *_422_*
• VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 and VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16

This however does not mean that it cannot be used with others.

[MarkCallow]

Please also update the line 880 to allow KHR_DF_MODEL_YUVSDA

Please take a look at latest commit.

[MarkCallow]

@lexaknyazev please approve the latest small clarification.

This however does not mean that it cannot be used with others.

I am using "should" so the clarification does not rule out using YUV with other formats.