RESOLVED FIXED 241850
REGRESSION(250984@main): [Linux] DrmFourCCFormatToGLInternalFormat() change breaks framebuffer blitting
https://bugs.webkit.org/show_bug.cgi?id=241850
Summary REGRESSION(250984@main): [Linux] DrmFourCCFormatToGLInternalFormat() change b...
Zan Dobersek
Reported 2022-06-22 03:18:53 PDT
ANGLE update at 250984@main brought in the following change: 36f5e6ce5 Vulkan: Fix DRM to GL format conversion https://chromium-review.googlesource.com/c/angle/angle/+/3624139 https://chromium.googlesource.com/angle/angle/+/36f5e6ce550870261998b77987d01c4a4e34e620 An XRGB8888 DMABuf is used as output for ANGLE execution. DrmFourCCFormatToGLInternalFormat(), called from the DmaBufImageSiblingEGL constructor, now returns a gl::Format object for the GL_BGRX8_ANGLEX internal format. This trips up the GL_BlitFramebufferANGLE() call, during the validation of attachments, with gl::Format::EquivalentForBlit() returning false for the read and draw attachments. Read attachment at that point has the GL_RGB8 sized internal format, but the draw attachment (with the DMABuf underneath) sticks to the GL_BGRX8_ANGLEX format. EquivalentBlitInternalFormat() helper maps GL_RGBX8_ANGLE to GL_RGB8 -- possibly it should do the same for GL_BGRX8_ANGLEX.
Attachments
Zan Dobersek
Comment 1 2022-06-22 12:16:43 PDT
Kenneth Russell
Comment 2 2022-06-24 16:50:29 PDT
The ANGLE bug indicates this has already been fixed upstream. We should roll forward ANGLE into WebKit again to pick up this and other fixes.
Radar WebKit Bug Importer
Comment 3 2022-06-29 03:19:13 PDT
Zan Dobersek
Comment 4 2022-07-01 00:12:24 PDT
Resolved with the update in #242055.
Note You need to log in before you can comment on or make changes to this bug.