KhronosGroup / OpenXR-CTS

Conformance test suite for OpenXR
https://www.khronos.org/conformance/adopters/
Apache License 2.0
66 stars 21 forks source link

case “SourceAlphaBlending”, Error to get the color. #64

Open xingchen0085 opened 1 year ago

xingchen0085 commented 1 year ago

When I test TEST_CASE("SourceAlphaBlending", "[composition][interactive][no_auto]"), the Runtime used Monado, and the resulting graphic results were as follows: mmexport1691658512931 I found that the colors of the three rectangles are not exactly the same. It is easy to see that the blue color of the middle rectangle is bluer. And in my runtime, the pipeline's color blend config is:

VkBlendFactor blend_factor = premultiplied_alpha ? VK_BLEND_FACTOR_ONE : VK_BLEND_FACTOR_SRC_ALPHA;
// final_color.rgb   = (new_color.rgb * srcColorBlendFactor) [colorBlendOp] (old_color.rgb * dstColorBlendFactor)
// final_color.alpha = (new_color.a * srcAlphaBlendFactor) [alphaBlendOp] (old_color.a * dstAlphaBlendFactor)
&(VkPipelineColorBlendAttachmentState){
    .blendEnable = VK_TRUE,
    .colorWriteMask = VK_COLOR_COMPONENT_R_BIT | VK_COLOR_COMPONENT_G_BIT | VK_COLOR_COMPONENT_B_BIT | VK_COLOR_COMPONENT_A_BIT,
    .srcColorBlendFactor = blend_factor,
    .dstColorBlendFactor = VK_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
    .colorBlendOp = VK_BLEND_OP_ADD,
    .srcAlphaBlendFactor = VK_BLEND_FACTOR_SRC_ALPHA,
    .dstAlphaBlendFactor = VK_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA,
    .alphaBlendOp = VK_BLEND_OP_ADD,
}

Is this correct? Hope to get your reply very much, thank you!

rpavlik-bot commented 1 year ago

An issue (number 2095) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2095 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

Wallbraker commented 1 year ago

This looks fine for me, what version of Monado are you using?

revane commented 3 months ago

I recently ran into this problem implementing this piece of composition. The issue is the CTS test is calculating colors in gamma space and then (implicitly) submitting layers on non-linear (i.e. sRGB) swapchains. Calculating premultiplied-alpha colors and calculating the expected result (the middle square) using gamma-encoded colors is not correct.

A simple solution would be to allocate linear-color swapchains.

revane commented 2 months ago

Digging into this further, the issue stems from the vkCmdBlitImage used to initialize the static swapchain image for the expected result. An SRGB swapchain is being created with images that have a UNORM format due to platform limitations. The images are marked mutable with SRGB as an allowed view format. However, the vkCmdBlitImage doesn't accept views and having only Images at its disposal, it transforms the source image (SRGB format) linear color to store in the destination image (UNORM format).

I'm not sure of the correct way forward. If we work with linear swapchains the vkCmdBlitImage will be fine. Otherwise, we need to avoid the Blit. Are there solutions other than a copy shader?