Concerns over removal of SwiftShader fallback

[Ashley Gullen]

Hi Blink developers,

I am concerned about this entry on Chrome Platform Status "Remove SwiftShader fallback", currently scheduled to ship in M133: https://chromestatus.com/feature/5166674414927872

There does not appear to be an associated bug, nor have I seen any intent to deprecate associated with this on blink-dev. It appears to be an unannounced unilateral decision by Google which I'm worried has the potential to have a big impact on products and web content relying on WebGL, like our commercial browser-based game engine Construct (www.construct.net).

For many years now web developers have been able to assume that WebGL support is ubiquitous. Numbers are hard to come by, but the best available are probably from Web3DSurvey (https://web3dsurvey.com/): WebGL 1 is supported on ~99.7% of devices, but ~2.7% of uses report "major performance caveat", which seems likely to indicate SwiftShader. At web scale, this is tens of millions of users. Worse, this survey may in fact be biased towards high-end users with more modern systems that are more likely to have hardware/driver support for WebGL - the real number could be larger. WebGPU still has much lower support numbers so that does not look like a workaround. Canvas2D is not a viable workaround for modern content, and the ubiquity of WebGL has meant even tools like Construct that used to support a Canvas2D fallback ultimately removed it and went all-in on WebGL.

I suspect for years we have been able to assume that WebGL support is ubiquitous in large part due to the Swiftshader fallback covering the last few percent of users who don't have suitable hardware/drivers. Content that works slowly is better than content that does not work at all, and I fear that removal of this fallback will result in companies like us, as well as other major users of WebGL (three.js, itch.io, etc.) being inundated with "your content stopped working!" complaints. I also find it hard to understand that "users have a poor experience" with the CPU fallback being given as a justification for this, as content that does not work at all is a far worse experience than having it run but slowly, and is far more likely to result in customers contacting support.

This could end up being a disaster for us. It would help ease my mind if Google could:

• Provide data about the Internet-scale usage of software fallback for WebGL demonstrating that removal will have minimal impact
• Use some other software fallback like WARP on Windows: https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp
• Provide software fallback for WebGPU so there is a possible workaround with the newer API
• At least delay this decision until there has been time to discuss with WebGL developers and determine the impact, identify workarounds, implement them and roll out the changes

It would also be useful if Google could explain the precise timeline for this - it's not clear whether M133 is the beginning of a deprecation period, or the point of removal.

Best regards

Ashley Gullen

Scirra Ltd

[Ashley Gullen]

Hi folks, it's been a week, is anyone from the relevant team able to review this and respond?

Best regards

Ashley

[François Beaufort]

According to https://issues.chromium.org/40277080, I believe geof...@chromium.org should be able to help you.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73gJTc1ur8v-aVR3rTsOa%3DeTmDHWEpNuPAyWHQkbUPFt5w%40mail.gmail.com.

[Geoff Lang]

Hey Ashley,

I suspect the M133 in the chrome status page will be updated to a later release. I also put the bug link (https://issues.chromium.org/40277080) on that page.

Thanks for the feedback. Right now we're in a situation where we definitely need to remove SwiftShader WebGL support but we're evaluating other ways to support fallback based on this kind of thread. WARP is a possibility but still suffers from continuing to run JITed code in processes that are high security risk and difficult to sandbox.

The "users have a poor experience" situation is more than just content running slowly. A common case where users result in software fallback is due to GPU driver crashes and hangs, to the user this is a series of flickers and hangs in the page followed by it running slowly because the whole browser switched to software rendering.

We'll likely update the feature page again once David is back from holiday.

Geoff

[Ashley Gullen]

Thanks for the response, I couldn't find that issue previously and I'm now following it.

From my point of view some other fallback is definitely necessary. I understand that a GPU crash may cause temporary interruption for someone's browsing experience, but content made by tools like Construct suddenly stopping working for potentially tens of millions of people seems like a far worse outcome than that. So I struggle to see how removing a fallback will do anything to improve the user experience, and could prove to be a disaster for commercial products like ours. I hope some other solution can be found.