| Summary: | REGRESSION (iOS 15.4 beta) - WebGL yields incorrect results when using preserveDrawingBuffer on iOS 15.4 Beta | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Christoph Bartschat <christoph> | ||||||
| Component: | WebGL | Assignee: | Kimmo Kinnunen <kkinnunen> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | avpeery, bfulgham, dino, ews-watchlist, gman, kbr, kkinnunen, kondapallykalyan, kpiddington, mmaxfield, mvaligursky, rigel, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | Safari 15 | ||||||||
| Hardware: | iPhone / iPad | ||||||||
| OS: | iOS 15 | ||||||||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=233977 https://bugs.webkit.org/show_bug.cgi?id=237906 |
||||||||
| Bug Depends on: | 238196 | ||||||||
| Bug Blocks: | 237230 | ||||||||
| Attachments: |
|
||||||||
This can actually be reproduced in Safari Technology Preview Release 140 (Safari 15.4, WebKit 17614.1.1.5) on M1 hardware, making it easier to diagnose. I wonder whether the ANGLE roll in Bug 235746 will affect this behavior - somewhat doubt it if this is a WebKit-side change. Note that this doesn't reproduce in the same version of Safari Technology Preview on Intel hardware. ANGLE roll in Bug 235746 does not fix this issue. Bisection initially points to r286645 bug 233977 Scratch that, second initial bisection points to bug 220896 r286603 Bug 235746 fixes https://greggman.com/downloads/examples/webgl/lessons/resources/webgl-preservedrawingbuffer-true.html Does not fix https://codepen.io/cmb8/pen/bGYKPrP This bug reproduces in Chromium, too, when using the ANGLE/Metal backend on M1 hardware. I used the tools to run a bisect there: ./src/tools/bisect-builds.py -a mac-arm -g 874000 -b 974000 --use-local-cache --verify-range -- --no-first-run --use-cmd-decoder=passthrough --use-angle=metal https://codepen.io/cmb8/pen/bGYKPrP which turned up: You are probably looking for a change made after 901356 (known good), but no later than 901367 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/047f67dec3ae1322e17a408954b12bf0e000a433..5eca15b4748370af38b90b98314d84523af8c6ba containing the ANGLE roll in which Apple's direct-to-Metal translator first began upstreaming last July: https://chromium.googlesource.com/chromium/src/+/3fc5546c60cfc7db7b3cf8c0d0c0ccf16927c850 https://chromium.googlesource.com/angle/angle.git/+log/b7cfbac4f8c5..2a668d9219dd so unfortunately this bug crept in a while ago and there's no fine-grained way to track it down. It probably occurred in this large patch: https://chromium-review.googlesource.com/c/angle/angle/+/2950067 and the reason this is showing up in 15.4 is that contains the ANGLE roll into WebKit from last December, Bug 220896. Looking through that patch, I doubt this is the problem but perhaps you'd like to try taking out the EXT_multisampled_render_to_texture code path on iOS as well: https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/src/libANGLE/renderer/metal/DisplayMtl.mm;l=907?q=DisplayMtl.mm The work-in-progress fix https://chromium-review.googlesource.com/c/angle/angle/+/3465937/ doesn't fix this either on the M1. This is almost surely a regression in the MTLStoreAction used to resolve the multisampled framebuffer; the multisampled contents have to be preserved after the blit to resolve, unless discarded. Can this be investigated from that standpoint? A note that there's a fix in review in upstream ANGLE which may fix this: https://chromium-review.googlesource.com/c/angle/angle/+/3506089 gman@'s upstream fix in ANGLE is confirmed to fix this bug: https://chromium-review.googlesource.com/c/angle/angle/+/3506089 Created attachment 454467 [details]
Patch
Created attachment 454468 [details]
Patch
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE Comment on attachment 454468 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=454468&action=review > Source/ThirdParty/ANGLE/ChangeLog:17 > + https://www.khronos.org/registry/webgl/sdk/tests/conformance2/renderbuffers/multisample-draws-between-blits.html Does this patch enable the test somehow? (In reply to Myles C. Maxfield from comment #17) > Comment on attachment 454468 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=454468&action=review > > > Source/ThirdParty/ANGLE/ChangeLog:17 > > + https://www.khronos.org/registry/webgl/sdk/tests/conformance2/renderbuffers/multisample-draws-between-blits.html > > Does this patch enable the test somehow? No, tests need to be rolled from the conformance test repo. Committed r291218 (248373@main): <https://commits.webkit.org/248373@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 454468 [details]. Hi all, is this fix going to be released in a patch for 15.4? It there a way to test this fix in a beta version? We have a similar problem: https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks! I can confirm that on iOS, (In reply to Anna from Mapbox from comment #20) > Hi all, is this fix going to be released in a patch for 15.4? It there a way > to test this fix in a beta version? We have a similar problem: > https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks! Hi Anna, I can't comment on when this fix will show up on iOS, but I can confirm that on iOS, this patch fixes your Mapbox regression. I'll make sure to mirror this information on your bug report. *** Bug 237918 has been marked as a duplicate of this bug. *** (In reply to Kyle Piddington from comment #21) > I can confirm that on iOS, (In reply to Anna from Mapbox from comment #20) > > Hi all, is this fix going to be released in a patch for 15.4? It there a way > > to test this fix in a beta version? We have a similar problem: > > https://bugs.webkit.org/show_bug.cgi?id=237918. Thanks! > > Hi Anna, > I can't comment on when this fix will show up on iOS, but I can confirm that > on iOS, this patch fixes your Mapbox regression. I'll make sure to mirror > this information on your bug report. Thanks Kyle for digging into this! We were able to do a patch release last week that disables antialiasing for 15.4 Safari to resolve this problem on our end. We found it reproducible in iOS 15.4 devices and M1 Macbooks. Hey all, so this issue is also happening for us on M1 Macbooks. We tested the newly released Safari Technology Preview Release 142 (Safari 15.4, WebKit 16614.1.5.16) on an M1 Mac and still see this issue. There isn't an iOS beta out yet to test on iOS. Does/Can this solution also apply to Safari (non iOS)? Thanks! Here's the jsbin example: https://jsbin.com/mojuyosenu/edit?html,css,js,output (In reply to Anna from Mapbox from comment #24) > Hey all, so this issue is also happening for us on M1 Macbooks. We tested > the newly released Safari Technology Preview Release 142 (Safari 15.4, > WebKit 16614.1.5.16) on an M1 Mac and still see this issue. There isn't an > iOS beta out yet to test on iOS. Does/Can this solution also apply to Safari > (non iOS)? Thanks! Here's the jsbin example: > https://jsbin.com/mojuyosenu/edit?html,css,js,output I think it will be in the next Safari Technology Preview. Sorry, it hasn't been updated in a while. This fix shipped with Safari 15.5 (all platforms). *** Bug 237230 has been marked as a duplicate of this bug. *** |
This is a regression between iOS 15.3.1 and 15.4. It appears that preserveDrawingBuffer is not taking effect. When we render a three.js scene with: const context = canvas.getContext('webgl', {preserveDrawingBuffer: true}) ... renderer.autoClear = false We expect that each frame is rendered on top of the previous frame, without replacing it. However, as can be see in this demo: https://codepen.io/cmb8/pen/bGYKPrP We should see a check mark getting drawn, but instead, we only see the circle moving across the screen, without leaving a trail. The problem occurs for both 'webgl' and 'webgl2' in the getContext call. Disabling "WebGL via Metal" in "Experimental WebKit Features" and relaunching Safari fixes the behavior. Video of expected behavior: https://youtu.be/4EpijoQe_Kw Video of unexpected behavior: https://youtu.be/YHNgSRgy8ag