Hello, We got reports from customers using Autodesk Forge Viewer that, since updating to IOS 15, very large models could not be loaded anymore and the browser tab completely freezes. On IOS14 the same models load without problems. They also load fine when deactivating the Safari experimental flag "WebGL via Metal". The console on the device contains the following error messages when the tab freezes: // IOReturn IOGPUDevice::new_resource(IOGPUNewResourceArgs *, struct IOGPUNewResourceReturnData *, IOByteCount, uint32_t *): PID 44130 likely leaking IOGPUResource (count=44000) // ... // IOReturn IOGPUDevice::new_resource(IOGPUNewResourceArgs *, struct IOGPUNewResourceReturnData *, IOByteCount, uint32_t *): PID 44130 likely leaking IOGPUResource (count=60000) The problem seems to occur in combination with multiple frame buffer objects, many geometry buffers and draw calls. Calling WebGLRenderingContext.flush() every couple thousand draw calls seems to prevent the issue. We were not able to reproduce the issue using an IOS simulator, but only on physical devices. On some devices the tab reports a problem and reloads instead of freezing. I created a minimal example application to show the issue: // this version consistently fails after roughly 11.500.000 draw calls (Tested on IPhone 11, IPhone 13, IPhone 13 Pro Max, IPad Pro 11 2Gen with IOS/IpadOS 15.4) https://sdunkel.github.io/IOS15TabFreeze/index.html // this version does a flush in between and doesn't seem to fail https://sdunkel.github.io/IOS15TabFreeze/index.html?flush Depending on the amount of allocated/used resources the number of usable draw calls before the tab freezes varies significantly. So in our application this is already the case after a few ten thousand draw calls. Thank you
I suspect this has already been addressed in top-of-tree WebKit with many other fixes that have been integrated. Submitter, does this happen on macOS with M1 hardware? That would make it easier to diagnose and confirm whether it's been fixed with Safari Technology Preview.
On an M1 MacBook Pro (16-inch, 2021) with Safari 15.4 (17613.1.17.1.13) I can reach 33.500.000 draw calls in the test app and then the tab crashes and reloads. I can't reproduce the freezing behaviour on the Mac though, so I can't say for sure whether it is exactly the same problem. Turning off "WebGL via Metal" or flushing the GL context prevents the crashes on the Mac as well. The console shows similar error messages: // IOReturn IOGPUDevice::new_resource(IOGPUNewResourceArgs *, struct IOGPUNewResourceReturnData *, IOByteCount, uint32_t *): PID 62576 likely leaking IOGPUResource (count=135000) // virtual bool IOGPUResource::map(uint64_t): failed to create mapping. resType=0x0 // IOReturn IOGPUDevice::new_resource(IOGPUNewResourceArgs *, struct IOGPUNewResourceReturnData *, IOByteCount, uint32_t *): failed to create mapping. // static IOReturn IOGPUDeviceUserClient::s_new_resource(IOGPUDeviceUserClient *, void *, IOExternalMethodArguments *) failed to create resource Same behaviour with Safari Tech Preview (15.4, WebKit 17614.1.7.7)
<rdar://problem/92854716>
Looking at the code, it seems that we only flush when we exceed a resident resource count. Either this isn't being calculated right, or we need more flush conditions. bool CommandBuffer::needsFlushForDrawCallLimits() const { return mWorkingResourceSize > kMaximumResidentMemorySizeInBytes; } We might need to tweak this to a maximum number of drawArrays calls too. 10k, maybe?
That seems reasonable though I would: 1) Count all draw calls, not just drawArrays calls. 2) Make the limit higher so long as that mitigates this reported problem - like 100K draw calls. 3) Write a WebGL conformance test that tries to expose the freezing. Please note that similar bugs were found in the past: https://github.com/KhronosGroup/WebGL/blob/main/sdk/tests/conformance/rendering/many-draw-calls.html and a reasonable place for any new test case could be: https://github.com/KhronosGroup/WebGL/tree/main/sdk/tests/conformance2/rendering