Bug 231471

Summary: REGRESSION (iOS 15, GPU Process): Fails to load texture map
Product: WebKit Reporter: Aaron Hilton <aaron>
Component: WebGLAssignee: Kimmo Kinnunen <kkinnunen>
Status: RESOLVED FIXED    
Severity: Critical CC: banane.more+webkit, bankey1443, bobketting, brianpeiris, dino, florent.masson, kbr, kkinnunen, kpiddington, smoley, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Safari 15   
Hardware: iPhone / iPad   
OS: iOS 14   
See Also: https://bugs.webkit.org/show_bug.cgi?id=232378
Bug Depends on:    
Bug Blocks: 232814, 233006, 232357, 232378    
Attachments:
Description Flags
Reproduction of bug on iPad Pro 11" 2nd Gen - iPadOS 15.0.1
none
Patch
none
Patch none

Aaron Hilton
Reported 2021-10-08 23:34:39 PDT
Created attachment 440701 [details] Reproduction of bug on iPad Pro 11" 2nd Gen - iPadOS 15.0.1 Fails to load textures when trying to load a 3D model from here: https://monocle.link/?bundle=3B44YJjIJrpi001Kdz23 Reproduced on: iPhone 12 Pro Max, 256 GB model iPad Pro 11" 2nd Gen Upon further investigating differences between iOS 14.8 and iOS 15.0.1 it seems that "GPU Process: Canvas Rendering" was enabled. Turning this feature off fixes loading the texture maps.
Attachments
Reproduction of bug on iPad Pro 11" 2nd Gen - iPadOS 15.0.1 (475.37 KB, image/jpeg)
2021-10-08 23:34 PDT, Aaron Hilton
no flags
Patch (15.01 KB, patch)
2021-11-05 12:27 PDT, Kimmo Kinnunen
no flags
Patch (28.46 KB, patch)
2021-11-09 06:08 PST, Kimmo Kinnunen
no flags
Alexey Proskuryakov
Comment 1 2021-10-11 09:26:34 PDT
I cannot reproduce this with iPhone 13 Pro and iOS 15.1 beta.
Radar WebKit Bug Importer
Comment 2 2021-10-15 23:35:16 PDT
Smoley
Comment 3 2021-10-18 12:43:59 PDT
I can reproduce this on the same config as Alexey. The textures appear while the loading bar is showing then disappear after loading completes.
Kimmo Kinnunen
Comment 4 2021-10-19 00:56:56 PDT
Can repro on various devices. Reload until textures are missing.
Riccardo Arena
Comment 5 2021-10-21 05:42:23 PDT
Can reproduce on iPhone 11/iOS 15.0.2. Takes a couple of page refreshes after a complete reboot.
Aaron Hilton
Comment 6 2021-10-21 06:00:08 PDT
Please note, the underlying model-viewer release v1.9.0, implemented a workaround. It mostly works, but still fails sometimes. Please see this issue in GitHub: https://github.com/google/model-viewer/pull/2832 Model-Viewer releases: https://github.com/google/model-viewer/releases
Kimmo Kinnunen
Comment 7 2021-10-22 03:03:28 PDT
Aaron, Would you have a repro steps with the model-viewer repository? I did: - download the release with the fix - uncomment the probable line with tempTarget.dispose() - npm run build - npm run serve - navigate to packages/modelviewer-dev - browse the examples I couldn't see the missing textures from any of the tests I could browse.
Kimmo Kinnunen
Comment 8 2021-10-27 02:52:04 PDT
Most likely this has to do with ImageBitmaps being resident in the Web process and GPUP or Web process running out of memory. Symptoms are typically: - black texture - GPUP crash via Jetsam. - GPUP crash via resource limit hit during memmove inside CG, probably when overcommitted allocation requests pages and fails This can be reproed on macOS by loading the test case first thing after starting the browser.
Kimmo Kinnunen
Comment 9 2021-11-05 12:27:09 PDT
Tim Horton
Comment 10 2021-11-08 11:24:21 PST
Comment on attachment 443423 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=443423&action=review > Source/WebKit/ChangeLog:10 > + to the shareble bitmap. Before, it was manually re-implementing this "shareble" spelling > Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp:184 > + // This is important for example in GPUP operation, where caches of big IOSurfaces > + // would cause GPUP memory limits to be exceeded. It's a bit odd for this code to talk about the GPUP at all; is this not technically just as problematic in-process? (and we just didn't notice because of the higher limit)? > Tools/ChangeLog:12 > + it seems that the WTF::memoryFootprint() measurement does not see all the > + memory releases the CG does. Weird. Is it about the autoreleasepool? I guess not because you say that pausing and inspecting the process reports the right thing.
Kimmo Kinnunen
Comment 11 2021-11-08 11:39:29 PST
(In reply to Tim Horton from comment #10) > > Source/WebCore/platform/graphics/cg/ImageBufferIOSurfaceBackend.cpp:184 > > + // This is important for example in GPUP operation, where caches of big IOSurfaces > > + // would cause GPUP memory limits to be exceeded. > > It's a bit odd for this code to talk about the GPUP at all; is this not > technically just as problematic in-process? (and we just didn't notice > because of the higher limit)? Yeah, maybe the comment is not really useful..
Kimmo Kinnunen
Comment 12 2021-11-09 06:08:41 PST
EWS
Comment 13 2021-11-11 11:46:07 PST
Committed r285644 (244145@main): <https://commits.webkit.org/244145@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 443687 [details].
Smoley
Comment 14 2022-01-10 12:37:20 PST
*** Bug 234894 has been marked as a duplicate of this bug. ***
florent.masson
Comment 15 2022-01-18 10:09:41 PST
Which version has this been fixed? I just tested with safari 15.2.1 and I have black textures The workaround in three.js posted here seems to work: https://discourse.threejs.org/t/textures-in-gltf-sometimes-display-black-but-only-on-ios/30520/26
Brent Fulgham
Comment 16 2022-02-12 19:26:28 PST
*** Bug 232378 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.