Fix texel data test

[Jiawei-Shao]

Issue: #

---

Requirements for PR author:

• [ ] All missing test coverage is tracked with "TODO" or .unimplemented().
• [ ] New helpers are /** documented */ and new helper files are found in helper_index.txt.
• [ ] Test behaves as expected in a WebGPU implementation. (If not passing, explain above.)
• [ ] Test have be tested with compatibility mode validation enabled and behave as expected. (If not passing, explain above.)

Requirements for reviewer sign-off:

• [ ] Tests are properly located in the test tree.
• [ ] Test descriptions allow a reader to "read only the test plans and evaluate coverage completeness", and accurately reflect the test code.
• [ ] Tests provide complete coverage (including validation control cases). Missing coverage MUST be covered by TODOs.
• [ ] Helpers and types promote readability and maintainability.

When landing this PR, be sure to make any necessary issue status updates.

[Jiawei-Shao]

Hi @Kangz and @jzm-intel ,

This PR is far from being mature enough but I'd like to discuss how to test the data conversion about texel data, and it seems the current way in the CTS is incorrect.

PTAL, thanks!

[jzm-intel]

Currently the WebGPU spec said

If the format has the -srgb suffix, then sRGB conversions from gamma to linear and vice versa are applied during the reading and writing of color values in the shader.

Since the sRGB conversions are heavily non-linear, we should expect the result floats end up within some certain error boundary, like the case we seen for WGSL tests.

Jiawei suggested that current PR follows the accuracy requirement of D3D spec, which might be reasonable. It seems that Vulkan spec only refers to the conversions formula, didn't mention the accuracy; and the Metal spec (7.7.7 Conversion Rules for sRGBA and sBGRA Textures, P285) said the same accuracy requirement

The precision of the above conversion must ensure that the delta between the resulting infinitely precise floating point value when converting result back to an unnormalized sRGB value but without rounding to an 8-bit unsigned integer value (call it r) and the original sRGB 8-bit unsigned integer color value (call it rorig) is <= 0.5

However, this seems like a gap in the WebGPU spec, not specifying the accuracy of such conversions. Maybe working group shall discuss this?

And another concern I have is, currently the WebGPU spec also said that

WebGPU does not provide color management. All values within WebGPU (such as texture elements) are raw numeric values, not color-managed color values.

WebGPU does interface with color-managed outputs (via GPUCanvasConfiguration) and inputs (via copyExternalImageToTexture() and importExternalTexture()). Thus, color conversion must be performed between the WebGPU numeric values and the external color values. Each such interface point locally defines an encoding (color space, transfer function, and alpha premultiplication) in which the WebGPU numeric values are to be interpreted.

Does this description conflict?

[Kangz]

Though I think we should get @kainino0x to take a look as well.

This doesn't conflict with the color space handling of GPUCanvasContext and friends because it is the responsibility of the rest of the Web platform to define these color spaces. rgba8unorm-srgb and bgra8unorm-srgb are part of the "number computations" of WebGPU and should work correctly.

[kainino0x]

This doesn't conflict with the color space handling of GPUCanvasContext and friends because it is the responsibility of the rest of the Web platform to define these color spaces. rgba8unorm-srgb and bgra8unorm-srgb are part of the "number computations" of WebGPU and should work correctly.

Right. For example:

• rgba8unorm textures are not color-managed as sRGB-linear; they very often actually contain sRGB-nonlinear values, display-native (nonlinear) values, or non-color values.
• rgba8unorm-srgb textures are not color-managed as sRGB; they apply sRGB's gamma conversion when read or written in certain ways, but do not have to be sRGB - for instance Display P3 also uses sRGB's gamma conversion, and it's a decent approximation of display-native gamma curves too.

(This is a useful explanation. I will file a bug to put it in the spec. https://github.com/gpuweb/gpuweb/issues/4587)

[jzm-intel]

Thanks @Kangz and @kainino0x for the explanations!