Bug 238118 – REGRESSION: MSAA + disable depth_test causes depth invalid depth buffer

• Status: RESOLVED
• Resolution: FIXED
• Component: ANGLE

[Brendan Duncan]

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

[Radar WebKit Bug Importer]

<rdar://problem/90572527>

[Alexey Proskuryakov]

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.

[Brendan Duncan]

This is an issue with 15.4. I'll attach videos of Chrome vs Safari 15.4. STP is the same as 15.4.

[Brendan Duncan]

Created attachment 455335 [details]
MSAA Depth Buffer Video: Chrome

[Brendan Duncan]

Created attachment 455336 [details]
MSAA Depth Buffer Video: Safari 15.4

[Kimmo Kinnunen]

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.

[Kenneth Russell]

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.

[Brendan Duncan]

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.

[Kenneth Russell]

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.

[Brendan Duncan]

Sure, will do.

[Brendan Duncan]

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.

[Brendan Duncan]

I submitted a conformance test PR at https://github.com/KhronosGroup/WebGL/pull/3395

[Kenneth Russell]

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.

[Brendan Duncan]

Thanks for the note about run-safari! Confirmed that this is fixed in ToT when running run-minibrowser.

[Kenneth Russell]

Great. It looks like the issue with run-safari on M1 MacBook Pros has already been reported as Bug 236829.

[Dean Jackson]

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

[Brent Fulgham]

This fix shipped with Safari 15.5 (all platforms).