Software information

There's a couple of subtests in test_multisample_resolve_strongly_typed that fail on Turnip:

{ DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, 0xffbcbcbc },
{ DXGI_FORMAT_R8G8B8A8_UNORM, DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, DXGI_FORMAT_R8G8B8A8_UNORM_SRGB, 0xffbcbcbc },

These subtests render into a 4x MSAA surface, writing float4(sample_id / 2, sample_id / 2, sample_id / 2, 1.0f) for each sample. vkd3d selects the render pass attachment path for resolution, so a downsampling resolve to 1x MSAA is produced, averaging the four samples in linear RGB to (0.5, 0.5, 0.5, 1.0) before converting that to sRGB, as per requirements for multisample resolves in D3D.

Vulkan seems to have more relaxed requirements, allowing weird results. Spec doesn't mention linear RGB being required for renderpass multisample resolves in 8.7. Render Pass Multisample Resolve Operations. For vkCmdResolveImage, the resolution is still implementation-specific in 20.6. Resolving Multisample Images.

CTS corroborates this. Tests covering sRGB downsampling through render pass attachments accept correct results in either linear RGB or sRGB (commit). Not that it makes sense to take downsampling results done in linear RGB and claim them to be sRGB.

In one render mode, Turnip ends up downsampling in linear RGB, so the CTS tests pass, behavior seems spec-compliant but doesn't align with D3D, failing these two tests -- linear RGB 0xff7f7f7f is produced instead of 0xffbcbcbc sRGB.

System information

• GPU: Adreno A750
• Driver: Mesa Turnip, main branch
• Wine version: wine-9.21 (Staging)
• VKD3D-Proton version: master branch, tag v2.14.1