Unexpected sRGB behaviour from the texture clearing during a render pass.

[vicenteferrari]

I am encountering some weird behaviour when running my wgpu-native program on Windows with the Vulkan backend.

Specifically it pertains to the result obtained when clearing the Window Surface Texture and the encoding and decoding of the sRGB
values that were set to be the clear color during that render pass.

The behaviour I expected was that the values given to WGPURenderPassColorAttachment.clearValue would be interpreted as non-sRGB, linear, decoded values, and they would be encoded into sRGB—that is, passed through the OETF—when writing to the Surface Texture. Given that the Surface Texture has an -Srgb format.

As far as I could see in the WebGPU specification, it does not mention what kind of values should be passed to clearValue. So I resorted the the Vulkan specification, which does talk about it. There is specified, that

float32 are the color clear values when the format of the image or attachment is one of the numeric formats with a numeric type that is floating-point. Floating-point values are automatically converted to the format of the image, with the clear value being treated as linear if the image is sRGB.

Alas, when I clear the screen during a render pass, the value is copied to the swap chain texture directly, without being transformed, but—and here is the weird part—not always.

When I launch the program through RenderDoc, it works properly! But both times—with and without Renderdoc—does the program report an -Srgb format for the Surface Capabilities of my Window Surface, and for the Texture gotten from it to render to.

The image shows the same program running under RenderDoc and being launched directly from Explorer.

A cursory inspection of the Render Pass through RenderDoc shows that the correct values are being passed to Vulkan, and those are correctly being transformed when written to the backbuffer. I sadly don't know how to look into this process without RenderDoc, which is when the behaviour is wrong... :(

Do you guys think this is a bug on the wgpu-core side, or something else? The only thing I can think of is that the Windows PixelFormat is different when running under these different conditions, but I already tried making an HDC with a non-srgb pixel format and it crashed immediately, I don't think Windows supports them anymore. That and given that wgpu reports an -Srgb format on both cases makes me think it's a wgpu internal bug...