I wrote about this previously but I'm still concerned this is a major
breaking change for existing published WebGL content on the web. If the
figure of 2.7% comes from my previous citing of Web3DSurvey (
https://web3dsurvey.com/) then this should be seen as very much an
underestimate, because that site uses a relatively small sample size that
is more likely to be focused on high-end devices (samples are taken from
developer-focused sites like the three.js website, WebGPU fundamentals
etc). I would not be surprised if the real worldwide average was more like
4-5%. Then if that's a worldwide average, there will probably be some
specific countries or markets where the figure could be more like 10%.

Suppose this change rolls out and we get reports that say our WebGL content
no longer works for 10% of users in a South American market. Then what?
There is nothing feasible we can do about it. These customers were
previously getting by with SwiftShader, but now they get an error message.
So I fear this risks disaster for web games in some markets.

Does Google have their own internal data about the usage of SwiftShader?
Can more data about this be shared? I respect the work done by Web3DSurvey
but unfortunately for the reasons I mentioned I don't think it should be
used as evidence to make such a big change as this. Maybe in some places it
will affect 25% or 50% of users - who knows? How can we be sure?

Can there not be some other fallback implemented? V8 does JIT with
untrusted JavaScript code and that is generally considered reasonably
secure, is there any particular technical reason SwiftShader is not
considered as secure?

I'd also point out that any website that has a poor experience with
SwiftShader can already opt-out using the failIfMajorPerformanceCaveat
context flag. If there is some other mode that can be used instead, or just
showing an error message is acceptable, then websites can already implement
that. In our case with Construct we specifically attempt to obtain
hardware-accelerated WebGPU, WebGL 2, or WebGL 1; only failing that do we
resort to using SwiftShader on the basis that showing the content with
potentially poor performance is better than not showing it at all.


On Thu, 13 Feb 2025 at 15:46, 'David Adrian' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> dadr...@google.com, geoffl...@chromium.org
>
> Summary
>
> Allowing automatic fallback to WebGL backed by SwiftShader is deprecated
> and will be removed. This has been noted in DevTools since Chrome 130.
>
> WebGL context creation will fail instead of falling back to SwiftShader.
> This is for two primary reasons:
>
> 1. SwiftShader is a high security risk due to JIT-ed code running in
> Chromium's GPU process.
>
> 2. Users have a poor experience when falling back from a high-performance
> GPU-backed WebGL to a CPU-backed implementation. Users have no control over
> this behavior and it is difficult to describe in bug reports.
>
> SwiftShader is a useful tool for web developers to test their sites on
> systems that are headless or do not have a supported GPU. This use case
> will still be supported by opting in but is not intended for running
> untrusted content.
>
> To opt-in to lower security guarantees and allow SwiftShader for WebGL,
> run the chrome executable with the --enable-unsafe-swiftshader command-line
> switch.
>
> During the deprecation period, a warning will appear in the javascript
> console when a WebGL context is created and backed with SwiftShader.
> Passing --enable-unsafe-swiftshader will remove this warning message. This
> deprecation period began in Chrome 130.
>
> Chromium and other browsers do not guarantee WebGL availability. Please
> test and handle WebGL context creation failure and fall back to other web
> APIs such as Canvas2D or an appropriate message to the user.
>
> SwiftShader is an internal implementation detail of Chromium, not a public
> web standard, therefore buy-in from other browsers is not required. The
> devices covered by SwiftShader (primarily older Windows devices) are likely
> already incompatible with WebGL in other browsers.
>
> SwiftShader is not used on mobile; this only applies to Desktop platforms.
>
> Blink component
>
> Blink>WebGL
> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EWebGL%22>
>
> Motivation
>
>
> https://chromium.googlesource.com/chromium/src/+/main/docs/gpu/swiftshader.md#automatic-swiftshader-webgl-fallback-is-deprecated
>
> Risks
>
> SwiftShader is used by devices without hardware acceleration for WebGL.
> This is approximately 2.7% of WebGL contexts. However, WebGL is considered
> fallible and in many cases, these draws are not performant and provide an
> effectively unusable experience for users. Many applications, such as
> Google Maps, prefer to fail out rather than use SwiftShader.
>
> Debuggability
>
> None
>
> Flag name on about://flags
>
> --enable-unsafe-swiftshader command-line switch.
>
> Finch feature name
>
> AllowSwiftShaderFallback
>
> Tracking bug
>
> https://issues.chromium.org/40277080
>
> Launch bug
>
> https://launch.corp.google.com/launch/4351104
>
> Estimated milestonesShipping on Desktop 137
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5166674414927872?gate=5188866041184256
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGkh42KV4DrSSyEgJaF4DnFOXAye-wRLrfD-LKGNkWhyWzshLA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jZ4PFS4pWzVBzPWkNzX6Lx96mVPHaG8QJoNFgaxFMmXA%40mail.gmail.com.

Reply via email to