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

Description Aaron Hilton 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.
Comment 1 Alexey Proskuryakov 2021-10-11 09:26:34 PDT
I cannot reproduce this with iPhone 13 Pro and iOS 15.1 beta.
Comment 2 Radar WebKit Bug Importer 2021-10-15 23:35:16 PDT
<rdar://problem/84328146>
Comment 3 Smoley 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.
Comment 4 Kimmo Kinnunen 2021-10-19 00:56:56 PDT
Can repro on various devices.
Reload until textures are missing.
Comment 5 Riccardo Arena 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.
Comment 6 Aaron Hilton 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
Comment 7 Kimmo Kinnunen 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.
Comment 8 Kimmo Kinnunen 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.
Comment 9 Kimmo Kinnunen 2021-11-05 12:27:09 PDT
Created attachment 443423 [details]
Patch
Comment 10 Tim Horton 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.
Comment 11 Kimmo Kinnunen 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..
Comment 12 Kimmo Kinnunen 2021-11-09 06:08:41 PST
Created attachment 443687 [details]
Patch
Comment 13 EWS 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].
Comment 14 Smoley 2022-01-10 12:37:20 PST
*** Bug 234894 has been marked as a duplicate of this bug. ***
Comment 15 florent.masson 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
Comment 16 Brent Fulgham 2022-02-12 19:26:28 PST
*** Bug 232378 has been marked as a duplicate of this bug. ***