If I render into a multisampled framebuffer, clear the render target, draw with DEPTH_TEST disabled, and then draw with DEPTH_TEST enabled, the second draw call is rendered incorrectly. Specifically, 1) I create a color + depth render buffer with more than 1 MSAA sample, 2) bind that framebuffer, 3) clear color + depth 4) disable DEPTH_TEST, depth mask 5) draw a quad 6) enable DEPTH_TEST, depth mask 7) draw a quad The second quad is drawn incorrectly. If you set MSAA samples to 1, or if you don't disable DEPTH_TEST, the render is correct. A test can be found here: https://github.com/brendan-duncan/webgl_bug_tests/blob/main/msaa_depth_buffer.html and viewed from here: https://brendan-duncan.github.io/webgl_bug_tests/msaa_depth_buffer.html
<rdar://problem/90572527>
This appears to work as expected (or at least same as Chrome) in Safari 15.3. Works differently in STP. I didn't check Safari 15.4.
This is an issue with 15.4. I'll attach videos of Chrome vs Safari 15.4. STP is the same as 15.4.
Created attachment 455335 [details] MSAA Depth Buffer Video: Chrome
Created attachment 455336 [details] MSAA Depth Buffer Video: Safari 15.4
Thanks for the report. I think this is part of the MSAA resolve 15.4 regression issue, added as the blocker. Note, there's another distinction, at least on my iMacPro1,1, AMD: the outer rectangle is white on OpenGL, black on Metal.
With the forthcoming ANGLE roll in Bug 238171, this test case will render correctly. (I'm not 100% sure whether it already renders correctly with top-of-tree WebKit.) This is a nice minimal test case - I'm not sure whether it's covered by other WebGL conformance tests but it would be great if you'd consider putting it into the conformance suite. Gregg recently uploaded https://github.com/KhronosGroup/WebGL/pull/3390 which I'm in the process of verifying now; if yours is a duplicate of that, then no need.
WebKit ToT still has the issue. I'll keep an eye out for the upcoming ANGLE update. This seems like the same issue Gregg added a test for. If it turns out not to be, then I'll happily simplify the test code and submit it to the suite.
Thanks for confirming the bug's still in ToT WebKit. Working to get the ANGLE roll green on the EWS bots so it can land tomorrow and fix this bug. Looking at your and Gregg's tests, they might be uncovering the same bug but have very different structures; yours uncovers issues with the depth test, and Gregg's uses the browser's internal multisampled renderbuffer resolution. If you'd consider porting it to the WebGL conformance framework - see https://github.com/KhronosGroup/WebGL/tree/main/sdk/tests/conformance2/rendering and recently added tests - we would greatly appreciate it. Thanks in advance.
Sure, will do.
I checked the WebKit main branch built from source again, and the issue is still there for me. I finished making a conformance test version of the test. I'll work on making a PR for that for the Khronos WebGL repo. One other triggering requirement I found was that it only fails for the second frame and onward from requestAnimationFrame. If I render a single frame, or render outside of requestAnimationFrame, then it rendered correctly. The conformance test version I made will reflect that.
I submitted a conformance test PR at https://github.com/KhronosGroup/WebGL/pull/3395
Thanks Brendan. Your original test, and conformance test, both pass with top-of-tree WebKit on an M1 MacBook Pro built and run via: ./Tools/Scripts/build-webkit --debug ./Tools/Scripts/run-minibrowser --debug Can you confirm? I think the run-safari script is broken right now and doesn't properly load the built WebKit.
Thanks for the note about run-safari! Confirmed that this is fixed in ToT when running run-minibrowser.
Great. It looks like the issue with run-safari on M1 MacBook Pros has already been reported as Bug 236829.
I confirmed this is fixed on iOS by the ANGLE roll https://bugs.webkit.org/show_bug.cgi?id=238171 (Should be in an upcoming beta release of iOS 15.5
This fix shipped with Safari 15.5 (all platforms).