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.
I cannot reproduce this with iPhone 13 Pro and iOS 15.1 beta.
<rdar://problem/84328146>
I can reproduce this on the same config as Alexey. The textures appear while the loading bar is showing then disappear after loading completes.
Can repro on various devices. Reload until textures are missing.
Can reproduce on iPhone 11/iOS 15.0.2. Takes a couple of page refreshes after a complete reboot.
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
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.
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.
Created attachment 443423 [details] Patch
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.
(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..
Created attachment 443687 [details] Patch
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].
*** Bug 234894 has been marked as a duplicate of this bug. ***
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
*** Bug 232378 has been marked as a duplicate of this bug. ***