Help needed debugging a WebGL1 performance issue on iPad Air 2020 / iPhone 12

[Lindsay Kay]

Hi group,

I'm debugging a severe performance regression of the xeokit SDK (https://xeokit.io) on the latest iPad Air devices, with no warnings or errors.

xeokit uses WebGL1, and currently runs at a staggeringly slow ~1FPS on those devices.

xeokit performs well on earlier iPads, Android, desktop Chrome/FF, and there are no WebGL warnings.

It's a complete mystery, so I'm just blindly disabling things until something changes.

So far, I've tried:

- Force medium precision in shaders
- Remove all image buffer allocations
- Remove all transparent rendering
- Disable default VBO binds after each frame
- Disable WebGL depth mask
- Smaller geometry batch sizes
- Disable all extensions

Current status:

- iPad 10.2" 2019 OK
- iPad 10.2" 2020 OK
- iPad Air 2019 OK

- iPad Air 2020 SLOW
- iPhone 12 SLOW

Can anyone recommend some other things to try? 

Here are my experiments so far: https://github.com/xeokit/xeokit-perf-test

Once we can work out what it's actually caused by, then I can make a minimal example to submit as an issue to the Safari/WebGL devs.

Thanks,

Lindsay

--

Lindsay Kay | Software Engineer

http://xeolabs.com

linds...@xeolabs.com

[Lindsay Kay]

PS. I'm using Spector to debug and it's awesome. 

In my tests, I've reduced xeokit shaders down to the bare minimum:

https://gist.github.com/xeolabs/9d3c99a22014a50665ff0d4afa73b366
https://gist.github.com/xeolabs/9802fc8cc3090892d5cbd765e78bf2ee

And I captured a snapshot of WebGL configs (below).

Still getting super slow performance on iPad Air 2020 and iPhone 12 though.

Just wondering if there are any known gotchas on these devices, that I should try fiddling with. We're at the "whack-a-mole" stage of chasing this issue ;)

[Ken Russell]

Hi Lindsay,

Could this be:

WebGL instanced draw calls are very slow on iPhone 12 Pro

https://bugs.webkit.org/show_bug.cgi?id=218949

?

If so, unfortunately this looks like a regression in the OpenGL ES driver on these devices.

You could confirm by replacing your instanced rendering draw call with individual draws. If it's much faster, then add that workaround, and try to figure out how to make it apply only on those devices for now.

Hopefully, the Metal backend in development for the ANGLE project will eventually eliminate this and other OpenGL and OpenGL ES-specific problems on Apple's platforms.

-Ken

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAJx3YTWaiNoUQHfXcMvFjYoxGzv3%2BteQ952%3D5r_R9Y_3FRA_LQ%40mail.gmail.com.

[Lindsay Kay]

Thanks Ken,

It's not the instanced draw calls in this case - I also tested with instancing disabled in xeokit, so can confirm that's not the cause.

Right now I'm getting the regression when rendering using xeokit's geometry batching renderer (which concatenates all the geometries into uber-VBOs for a single draw call). The shaders for that render path (after many things disabled) are super simple.

Just in case anything jumps out at anyone, I've also included the initial WebGL state settings obtained using Spectre - maybe there's a magic combo of settings in there that's known to cause problems...

Thanks again

Lindsay

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAMYvS2c4sDhM7ve0B01tTpxzyvX5DovjhUd85cAeqPdd70xN%2Bg%40mail.gmail.com.

[Ken Russell]

Nothing jumps out as strange in your context state setup.

Have you been able to boil this down to a smaller test case? Maybe it's related to the size of the VBOs or the number of primitives in the draw calls you're making.

-Ken

To view this discussion on the web visit https://groups.google.com/d/msgid/webgl-dev-list/CAJx3YTWt0Dw8sOwk%2BLLrV5MPmUF_sJ7N_Jo_jSTjk_zoZ3gbLQ%40mail.gmail.com.