Bug 238118

Summary:

REGRESSION: MSAA + disable depth_test causes depth invalid depth buffer

Product:

WebKit

Reporter:

Brendan Duncan <brendanduncan>

Component:

ANGLE

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

bfulgham, dino, geofflang, gman, jonahr, kbr, kkinnunen, kpiddington, webkit-bug-importer

Priority:

Keywords:

InRadar

Version:

Safari 15

Hardware:

Unspecified

OS:

macOS 10.15

See Also:

https://bugs.webkit.org/show_bug.cgi?id=238197
https://bugs.webkit.org/show_bug.cgi?id=236829

Bug Depends on:

238171, 238196

Bug Blocks:

Attachments:

Description	Flags
MSAA Depth Buffer Video: Chrome	none
MSAA Depth Buffer Video: Safari 15.4	none

Description Brendan Duncan 2022-03-19 15:00:20 PDT

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

Comment 1 Radar WebKit Bug Importer 2022-03-21 09:25:33 PDT

<rdar://problem/90572527>

Comment 2 Alexey Proskuryakov 2022-03-21 22:23:21 PDT

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.

Comment 3 Brendan Duncan 2022-03-21 22:52:38 PDT

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

Comment 4 Brendan Duncan 2022-03-21 22:54:36 PDT

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

Comment 5 Brendan Duncan 2022-03-21 22:57:09 PDT

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

Comment 6 Kimmo Kinnunen 2022-03-22 02:33:29 PDT

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.

Comment 7 Kenneth Russell 2022-03-22 12:01:40 PDT

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.

Comment 8 Brendan Duncan 2022-03-22 13:27:28 PDT

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.

Comment 9 Kenneth Russell 2022-03-22 15:53:02 PDT

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.

Comment 10 Brendan Duncan 2022-03-22 16:01:36 PDT

Sure, will do.

Comment 11 Brendan Duncan 2022-03-24 13:13:14 PDT

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.

Comment 12 Brendan Duncan 2022-03-24 15:09:47 PDT

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

Comment 13 Kenneth Russell 2022-03-24 16:20:29 PDT

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.

Comment 14 Brendan Duncan 2022-03-24 16:27:40 PDT

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

Comment 15 Kenneth Russell 2022-03-24 16:35:43 PDT

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

Comment 16 Dean Jackson 2022-03-28 17:48:48 PDT

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

Comment 17 Brent Fulgham 2022-05-26 15:04:07 PDT

This fix shipped with Safari 15.5 (all platforms).