Handling of SRGB vertex formats is confusing

[etang-cw]

Section 21.3.1 of the spec makes no mention of running an sRGB to linear conversion for SRGB formats. The CTS seems to take this as an indication that SRGB vertex formats should be treated identically to UNORM formats. MoltenVK and RADV both support SRGB vertex buffers, and I assume have implemented them in this way (confirmed for MoltenVK).

On the other hand, the VkFormat description makes no mention of this special handling, and states that the formats are all "stored with sRGB nonlinear encoding". In addition, I think most people would expect that the same color data with the same format would come up the same regardless of whether you loaded it from a texel buffer or a vertex attribute.

I think one of the following changes would improve clarity:

• Update VkFormat's docs to specifically mention that SRGB formats are treated as linear when used with vertex attributes
• Update 21.3.1 to say that sRGB to linear conversion should happen on vertex buffers, and update CTS accordingly

[Tobski]

Thanks for your feedback! We'll have a look at this, it does seem that treating it as UNORM is what the spec states, we're having a look at our options and will let you know when we figure what we want to do.

[HansKristian-Work]

RADV both support SRGB vertex buffers

does it?

I've tried a bunch of implementations on desktop and I've found no driver that supports RGBA8_SRGB vertex buffers.

• RADV
• AMD proprietary Linux/Windows
• NV Linux/Windows
• Intel Mesa/Windows

Looking at RADV source, there's an explicit "if srgb return false" in VBO feature query.

[HansKristian-Work]

Tried looking at CTS for this and there is
dEQP-VK.pipeline.monolithic.vertex_input.single_attribute.vec4.as_r8g8b8a8_srgb_rate_vertex and friends, but I cannot figure out what it's actually trying to test.

[etang-cw]

does it?

I was going off https://vulkan.gpuinfo.org/listdevicescoverage.php?bufferformat=R8G8B8A8_SRGB&featureflagbit=VERTEX_BUFFER&platform=linux for that one, the only one I've actually confirmed support for is MoltenVK

Edit: Looking more closely, it looks like it's only actually supported by some older version of RADV, which makes it show up in the list even though newer drivers don't support it.

And yeah, that's the test that seems to verify that R8G8B8A8_SRGB loads identically to _UNORM (and failed when I accidentally made MoltenVK load it as sRGB)

[HansKristian-Work]

the sRGB vertex format couldn't be captured in RDoc (probably blocks sRGB vertex support), but the UNORM test could be captured.

I think this means it's indeed trying values that are not 0 or 1, so it should at least be sensitive to sRGB decode happening or not.

[HansKristian-Work]

Found the snippet that generates GLSL and UNORM and sRGB have the same code. There is no sRGB curve applied to verification here, so I think the CTS intends for sRGB to be decoded as UNORM for attributes, indeed.

			else if (isVertexFormatUnorm(attributeInfo.vkType) || isVertexFormatSRGB(attributeInfo.vkType))
			{
				const float representableDiff = isVertexFormatPacked(attributeInfo.vkType) ? getRepresentableDifferenceUnormPacked(attributeInfo.vkType, orderNdx) : getRepresentableDifferenceUnorm(attributeInfo.vkType);

				if (isVertexFormatPacked(attributeInfo.vkType))
					glslCode << indentStr << "if (abs(" << accessStr << " - " << "clamp((" << representableDiff << " * (" << totalComponentCount << ".0 * float(" << indexId << ") + " << componentIndex << ".0)), 0.0, 1.0)) < " << threshold[orderNdx] << ")\n";
				else
					glslCode << indentStr << "if (abs(" << accessStr << " - " << "(" << representableDiff << " * (" << totalComponentCount << ".0 * float(" << indexId << ") + " << componentIndex << ".0))) < " << threshold[rowNdx] << ")\n";
			}