Summary: | Browser hangs with basic webgl usage such as showing pixi.js examples | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | florent.masson | ||||
Component: | WebGL | Assignee: | Kyle Piddington <kpiddington> | ||||
Status: | NEW --- | ||||||
Severity: | Critical | CC: | dino, ews-watchlist, florent.masson, johncunningham, kbr, kkinnunen, kondapallykalyan, kpiddington, timmmc, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | Safari 15 | ||||||
Hardware: | All | ||||||
OS: | iOS 15 | ||||||
Attachments: |
|
Description
florent.masson
2022-01-24 07:32:59 PST
Wonder whether this is a duplicate of a previously reported bug which has been fixed on ToT. Only Apple engineers can build for iOS, so hoping they can triage. Hey there, any update on this issue? I just updated my device with ios 15.3 and it's still broken Thanks Hi Florent, I'm not able to reproduce this issue on an iPhone 7 Plus while on iOS 15.2.1. This might be hardware / platform specific. To help us debug, can you try going to the following setting? Settings->Safari->Advanced->WebGL Via Metal and disable that option? Thank you for reporting! Hi Kyle, thanks for your help! Disabling "WebGL Via Metal" does indeed seems to fix the issue. I thought I has tested that previously with 15.2.1 but I probably failed to kill safari properly. My device is iPad Air 2 MNV22NF/A Is there any way to detect if this option is enabled and hint users to disable it? Thanks I'm seeing the same issue in Safari on iPad Air 2 devices with, OS versions 15.2.1 and 15.3, model number MGL12LL/A, but this does not repro on iPhone XR, iPhone 13 or iPad Gen 6. I'm also seeing the issue fixed by disabling "Settings->Safari->Advanced->WebGL Via Metal". My use case is slightly different, WebGL content loaded using WKWebView in an iOS/iPadOS app, and it results in an app crash in that scenario. From what I can tell, disabling the Safari setting "Settings->Safari->Advanced->WebGL Via Metal" does not impact WKWebView's behavior. Here are some more examples that trigger this issue https://phaser.io/examples/v3/view/actions/grid-align https://phaser.io/examples/v3/view/actions/inc-x-layers Would a fix for Safari also impact WKWebView? (In reply to tbomb80 from comment #5) > I'm seeing the same issue in Safari on iPad Air 2 devices with, OS versions > 15.2.1 and 15.3, model number MGL12LL/A, but this does not repro on iPhone > XR, iPhone 13 or iPad Gen 6. I'm also seeing the issue fixed by disabling > "Settings->Safari->Advanced->WebGL Via Metal". > > My use case is slightly different, WebGL content loaded using WKWebView in > an iOS/iPadOS app, and it results in an app crash in that scenario. From > what I can tell, disabling the Safari setting > "Settings->Safari->Advanced->WebGL Via Metal" does not impact WKWebView's > behavior. > > Here are some more examples that trigger this issue > https://phaser.io/examples/v3/view/actions/grid-align > https://phaser.io/examples/v3/view/actions/inc-x-layers > > > Would a fix for Safari also impact WKWebView? This looks related to https://bugs.webkit.org/show_bug.cgi?id=228904 Hi all, I've noticed that PixiJS version 4 samples still run correctly with the Metal backend. I know that asking the differences between V4 and V5 is an unreasonable ask, but is it possible there's a difference in WebGL1 and 2 support? Hi Kyle, I can confirm, having checked pixi's code, that lastest versions of pixi will attempt to create a webgl2 context while v4 will only create webgl context. I've tested with my device and the first 3 samples will run on pixi v4 but not these two: https://pixijs.io/examples-v4/#/masks/graphics.js https://pixijs.io/examples-v4/#/plugin-projection/cards.js (they run without WebGL Via Metal) Also, my problematic games all use pixi v4 and therefore do not create webgl2 contexts Hi, the issue is still present in 15.3.1 Hello, The issue is still present in 15.4.1. Are there any updates available from the WebKit team on this issue? Thanks, Tim. Created attachment 459742 [details]
Patch
Note that there are important steps to take when updating ANGLE. See https://trac.webkit.org/wiki/UpdatingANGLE Comment on attachment 459742 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=459742&action=review > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:811 > + if(mImplicitMultisampleStoreAction == MTLStoreActionDontCare) I feel there must be a better way to select the codepath. like pass the context or display as parameter to the FramebufferMtl constructor.. > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:1149 > + colorAttachment.storeAction = getMultisampleResolveStoreAction(context); so if I understand correctly, the issue is that Apple2 GPU family doesn't support MTLStoreActionStoreAndMultisampleResolve? And this patch: 1. fixes the GPU restarts on GPU family Apple2 when doing multisampled rendering with preserveDrawingBuffer == false 2. "breaks" the GPU family Apple2 when doing multisampled rendering with preserveDrawingBuffer == true. With the caveat about "breaks" that it never worked anyway, as it would cause GPU restart to fix 2, we'd need additional patch 3. that implements manual resolve blit? And in this patch, we would touch these call sites to say "storeAction = MTLStoreActionStore", and then the resolve would happen in the resolve step in onFrameEnd? (In reply to Kimmo Kinnunen from comment #14) > Comment on attachment 459742 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=459742&action=review > > > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:811 > > + if(mImplicitMultisampleStoreAction == MTLStoreActionDontCare) > > I feel there must be a better way to select the codepath. > like pass the context or display as parameter to the FramebufferMtl > constructor.. > > > Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:1149 > > + colorAttachment.storeAction = getMultisampleResolveStoreAction(context); > > so if I understand correctly, the issue is that Apple2 GPU family doesn't > support MTLStoreActionStoreAndMultisampleResolve? > And this patch: > 1. fixes the GPU restarts on GPU family Apple2 when doing multisampled > rendering with preserveDrawingBuffer == false > 2. "breaks" the GPU family Apple2 when doing multisampled rendering with > preserveDrawingBuffer == true. With the caveat about "breaks" that it never > worked anyway, as it would cause GPU restart > > to fix 2, we'd need additional patch 3. that implements manual resolve blit? > And in this patch, we would touch these call sites to say "storeAction = > MTLStoreActionStore", and then the resolve would happen in the resolve step > in onFrameEnd? That sounds correct to me, we'd need to add in a better resolve path for GPUFamily2. |