Bug 232271 – REGRESSION (iOS 15): Fragment shader performance is several times worse

• Status: NEW
• Component: WebGL

[Brian Richardson]

We've noticed a performance regression when having a lot of work inside of a fragment shader. I happened to have an iPad Air (3rd gen) that was still on iOS 14 so I could do a proper test.

I reproduced it with a small Three.JS testbed:

iOS15, iOS14, Test
60, 60, https://depot.knowhere.net/ios15regression/?num=5 
6, 55, https://depot.knowhere.net/ios15regression/?num=6
4, 33, https://depot.knowhere.net/ios15regression/?num=10

I see the same cliff at num=6 with my iPhone 12 Pro.  

Normally, I'd just say that's the perf cliff and call it good.  But it's odd that it's changed so much between 14 and 15, maybe something can be done?

[Kimmo Kinnunen]

Thank you for the report. If you have time, a test case where three.js and the payload app code is unbundled and both are not minified would be most useful. 

I can reproduce the issue. Reproduces also on macOS, AMD. The GPU work increases very much when using ANGLE Metal backend.

[Brian Richardson]

Hello Kimmo:

Thanks for taking the time to look into this.  I've updated the example to use just vanilla HTML/JS and an external version of Three.JS. I hope that makes things easier!

[Radar WebKit Bug Importer]

<rdar://problem/84688595>

[Kimmo Kinnunen]

(In reply to Brian Richardson from comment #2)
> Hello Kimmo:
> 
> Thanks for taking the time to look into this.  I've updated the example to
> use just vanilla HTML/JS and an external version of Three.JS. I hope that
> makes things easier!

Thanks!
The update does not seem to work on Safari?

"[Error] TypeError: Module specifier, 'three' does not start with "/", "./", or "../". Referenced from https://depot.knowhere.net/ios15regression/?num=5
	promiseReactionJob"

(It does work on Chrome, though..)

[Brian Richardson]

(In reply to Kimmo Kinnunen from comment #4)

> The update does not seem to work on Safari?

Fixed. I thought it'd be a fun time to try import maps, I guess when I tested on my phone it was using a cached version.  Removed that and it works in Safari for me!

[Brian Richardson]

Created attachment 442606 [details]
Test case showing the issue.  If you run with /?num=6 you'll see the perf cliff vs /?num=5

[Sébastien VIDECOQ]

Hello, any progress on this bug ? 
It deeply impacts our product, FPS has dropped from 60 to 2 FPS.

Adding another test sample that illustrate the behavior.
Thanks in advance.

[Sébastien VIDECOQ]

Created attachment 445098 [details]
another test case

[Brian Richardson]

Sébastien:

In our case, manually unrolling the loop seems to work around the issue. Give it a shot! Hope that helps!

Brian

[Sébastien VIDECOQ]

Brian, thanks a lot for the advice, we already gave a quick try this afternoon, but we are far from getting back performances of iOS 14. Maybe we are now facing  another iOS 15 regression ? We will try again tomorrow and provide feedbacks.

[Kyle Piddington]

Hi all! Some updates for you. Apologies for the delay.

We've identified the main issue here. Part of our shader transformation passes tries it's best to preserve the original GLSL struct while following Metal alignment best practices. 

What this means for the attached shaders is that we're promoting the vec3 uniforms to vec4 for sending over as uniform data, but are then converting back to vec3 in the MSL shader. This temporary variable is able to be stored in shader registers, up until the arrays get too big. 

We'll have a fix in on our end, but if you need faster performance in the meantime, try changing your vec3 variables to vec4.

[Kyle Piddington]

Created attachment 449452 [details]
Workaround demonstrating how uniform data type affects performance