241850 2022-06-22 03:18:53 -0700 REGRESSION(250984@main): [Linux] DrmFourCCFormatToGLInternalFormat() change breaks framebuffer blitting 2022-07-01 00:12:24 -0700 1 1 1 Unclassified WebKit ANGLE WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=240894 https://bugs.chromium.org/p/angleproject/issues/detail?id=7452 InRadar P2 Normal --- 242055 237649 1 zan webkit-unassigned alex dino kbr kkinnunen kpiddington webkit-bug-importer oldest_to_newest 1877266 0 zan 2022-06-22 03:18:53 -0700 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. 1877365 1 zan 2022-06-22 12:16:43 -0700 Reported upstream: https://bugs.chromium.org/p/angleproject/issues/detail?id=7452 1878295 2 kbr 2022-06-24 16:50:29 -0700 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. 1878985 3 webkit-bug-importer 2022-06-29 03:19:13 -0700 <rdar://problem/96127632> 1879669 4 zan 2022-07-01 00:12:24 -0700 Resolved with the update in #242055.