Matt, I'm seeing similar. Repro steps:
1/ Uninstall graphics driver for integrated Intel graphics using Device Manager. Reboot. On reboot, observe Device Manager reports graphics now as "Microsoft Basic Display Adapter". 2/ Run "c:\Program Files\Google\Chrome\Application\chrome.exe" --enable-features=AllowD3D11WarpFallback --disable-features=AllowSoftwareGLFallbackDueToCrashes,AllowSwiftShaderFallback 3/ Open chrome://gpu Observe WebGL shows as Unavailable. "Display type" shows as ANGLE_D3D11 rather than ANGLE_D3D11_WARP. Interestingly, if I open chrome://settings/system, and switch "Use graphics acceleration when available" to disabled and relaunch, WARP will activate. chrome://gpu will report WebGL as "Software only" and "Display type" will show as ANGLE_D3D11_WARP. Is it expected that WARP will only activate if "Use graphics acceleration when available" is disabled? I worry a lot of our customers will have this defaulted to enabled even with missing GPU drivers, and possibly may not have access to toggle if the machine is sufficiently locked down. The old / current behavior is that SwiftShader will activate under "Microsoft Basic Display Adapter" even if "Use graphics acceleration when available" is enabled. On Wednesday, September 3, 2025 at 1:01:25 PM UTC-7 RUI LI wrote: > Hi Geoff, > > Got it! Thank you so much for the detailed explanation. Things are much > clearer to us now! > > Thanks, > Rui > > On Tuesday, September 2, 2025 at 1:42:23 PM UTC-4 Geoff Lang wrote: > >> Hey, >> >> Chrome can roll out features with server-side configurations to do A/B >> comparisons or fix breakages without re-releasing, that's what's happening >> here. Starting in 139, some users are opted into the deprecation. More will >> be opted in over time until 100%. >> >> We're considering unblocking llvmpipe but it needs a lot more testing. It >> has a lot of version variance compared to WARP and is more difficult to >> test. It will also need some small architectural changes to use it for >> WebGL only while the rest of the browser uses software rasterization. >> >> If WARP is unavailable on Windows, there will be no software WebGL >> fallback. I have never seen this happen but it may be possible if the user >> has found a way to explicitly disable WARP. >> >> No software rendering alternatives are planned except continuing to >> investigate the mesa software renderers. >> >> No plans to remove SwiftShader, it will remain available by command line >> flag. The timeline of disabling SwiftShader fallback on Windows is the same >> as the other OSs except it's replaced by WARP there. >> >> Geoff >> >> On Wed, Aug 27, 2025 at 10:29 PM RUI LI <liru...@gmail.com> wrote: >> >>> Hi Geoff, thank you so much for your responses! To provide more context, >>> I work at a company where tens of thousands of our users currently fall >>> back to SwiftShader based on our analytics. This deprecation/removal would >>> pose a huge impact to us, so we want to be fully prepared and ensure a >>> smooth transition strategy. I have a few follow-up questions below and >>> would appreciate any further clarification: >>> >>> - Regarding your comment, “*the rollout is happening slowly within >>> the 139 release,*” could you please elaborate on what “*the rollout >>> is happening slowly*” means? >>> >>> >>> - On the topic of Linux software alternatives, you mentioned: “*It’s >>> unlikely that Chrome can ship with its own packaged lavapipe, but I want >>> to >>> make sure it’s used if it’s installed already.”* Should we expect >>> that on Linux, once SwiftShader is disabled, Chrome may fallback to >>> lavapipe (Vulkan-based) if it’s available? I am also curious if there >>> are >>> specific reasons why llvmpipe (OpenGL-based) is blocked via the >>> software_rendering_list.json (unlike Firefox, which allows it) — is this >>> due to security or stability issues? >>> >>> >>> - David mentioned that you are currently “*Replacing SwiftShader >>> with WARP on Windows.*” If I’m understanding correctly, SwiftShader >>> will only be disabled on Windows when the WARP replacement is ready, so >>> there will be no gap in software rendering support. Is that accurate? >>> >>> >>> - We would also like to know if there are any other software >>> rendering alternatives currently planned. We ask this because we would >>> like >>> to evaluate/test these renderers to ensure our WebGL programs will still >>> work. >>> >>> >>> - Lastly, I know this may be unplanned, but I just wanted to check: >>> do you have any timeline for when (and in which version) SwiftShader >>> might >>> be disabled on Windows? And when SwiftShader will be removed entirely? >>> >>> Thanks! >>> On Wednesday, August 27, 2025 at 10:04:18 AM UTC-4 Geoff Lang wrote: >>> >>>> It is the expected behaviour. The rollout is happening slowly within >>>> the 139 release. >>>> >>>> There are no plans for a default software fallback on Linux right now >>>> but we're thinking about the issue. I think it's unlikely that Chrome can >>>> ship with its own packaged lavapipe but I want to make sure it's used if >>>> it's installed already. You can also bypass the deprecation using command >>>> line flags, this is an important path to maintain for web developers and >>>> automated testing. >>>> >>>> Geoff >>>> >>>> On Mon, Aug 25, 2025 at 8:11 PM RUI LI <liru...@gmail.com> wrote: >>>> >>>>> Hi David and other folks, >>>>> >>>>> I am testing SwiftShader on a Debian 12 machine without hardware >>>>> acceleration. It seems that SwiftShader is still enabled (I saw >>>>> swiftshader >>>>> in Chrome://gpu) in Chrome 139. Is this the expected behavior? >>>>> >>>>> Also, I am curious about software rendering alternatives on Linux >>>>> machines. Similar to WARP, do you have any plans to replace SwiftShader >>>>> with MESA llvmpipe on Linux? I know there are also some Linux VM users >>>>> who >>>>> might also be affected by this removal. >>>>> >>>>> Thanks! >>>>> Rui >>>>> >>>>> On Wednesday, July 9, 2025 at 11:35:32 AM UTC-4 David Adrian wrote: >>>>> >>>>>> An update: We added an enterprise policy >>>>>> <https://chromeenterprise.google/policies/#EnableUnsafeSwiftShader> >>>>>> that allows users to re-enable Swiftshader. This should help with the >>>>>> managed VM / remote desktop use-case. >>>>>> >>>>>> In Chrome 139, we will start experimenting (via Finch/partial >>>>>> deployments) with: >>>>>> >>>>>> - Removing Swiftshader support on MacOS and Linux >>>>>> - Replacing Swiftshader with WARP on Windows >>>>>> - Removing the OOM fallback to Swiftshader/WARP, so that it is >>>>>> not attacker-triggerable on arbitrary devices >>>>>> >>>>>> >>>>>> On Thursday, April 24, 2025 at 9:55:58 AM UTC-4 David Adrian wrote: >>>>>> >>>>>>> As it stands now, we are hopeful we can swap out to WARP on Windows >>>>>>> without any drop in coverage for software rendering (i.e. >>>>>>> simultaneously >>>>>>> with removing SwiftShader). Experimental support and testing for this >>>>>>> will >>>>>>> begin in Chrome 137. >>>>>>> >>>>>>> On Thursday, April 10, 2025 at 12:47:33 PM UTC-4 Julie Powell wrote: >>>>>>> >>>>>>>> WebGL emulation is critical for many US entities that are running >>>>>>>> thin client machines which don’t have access to a GPU. So far, the >>>>>>>> organizations we’ve spoken to are on Windows so simultaneously putting >>>>>>>> an >>>>>>>> automatic fallback to WARP in place once the fallback to SwiftShader >>>>>>>> is >>>>>>>> removed – avoiding a period of time when a command line override would >>>>>>>> be >>>>>>>> required – will allow them to continue operating. We have verified >>>>>>>> that the >>>>>>>> following organizations are dependent on this capability (note that >>>>>>>> there >>>>>>>> are many more outside of this list, both in the private and public >>>>>>>> sector): >>>>>>>> Department of the Interior Bureau of Land Management, Office of >>>>>>>> Wildland >>>>>>>> Fire, National Park Service, U.S. Geologic Survey, U.S. Fish and >>>>>>>> Wildlife >>>>>>>> Service, Bureau of Indian Affairs, Air Force DCGS, Army Tactical Edge >>>>>>>> Node, >>>>>>>> DCGS-Army, DCGS-USMC, USMC, USAF, USDA, NGA, DIA, Census, DHS, CISA, >>>>>>>> FirstNet/NTIA (Commerce), NCIS, DTRA, STRATCOM, EUCOM, Idaho National >>>>>>>> Guard, some universities, K-12 schools, National Geographic, and more. >>>>>>>> >>>>>>>> I am working with colleagues and international distributors to >>>>>>>> gauge the usage of VMs running Linux which are doing web mapping and >>>>>>>> don’t >>>>>>>> have access to GPU resources. I will come back with an update when I >>>>>>>> have >>>>>>>> one. >>>>>>>> >>>>>>>> On Monday, March 24, 2025 at 12:56:08 PM UTC-7 Matt George wrote: >>>>>>>> >>>>>>>>> Hi Rick, AFAIK it's only Windows, but currently reaching out to >>>>>>>>> see if it's different for our distributors in Europe. >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> On Monday, March 24, 2025 at 10:38:19 AM UTC-7 Rick Byers wrote: >>>>>>>>> >>>>>>>>>> Thanks for chiming in Matt. Is the scenario you described >>>>>>>>>> Windows-only (in which case we should be good with WARP), or also >>>>>>>>>> Linux? >>>>>>>>>> >>>>>>>>>> Rick >>>>>>>>>> >>>>>>>>>> On Mon, Mar 24, 2025 at 1:22 PM Matt George <matt...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Very happy to hear about exploring the use of WARP on windows. >>>>>>>>>>> >>>>>>>>>>> Just wanted to chime in that from the Esri perspective, we also >>>>>>>>>>> have a large number of users accessing our maps SDK from VMs >>>>>>>>>>> without a GPU. >>>>>>>>>>> This is done for security reasons, & not uncommon for public sector >>>>>>>>>>> clients. We have a special codepath where when we detect software >>>>>>>>>>> emulation >>>>>>>>>>> is being used, we only render every X frames & then use css >>>>>>>>>>> transforms >>>>>>>>>>> in-between. This is fairly usable, though of course it's a much >>>>>>>>>>> worse >>>>>>>>>>> experience than having a GPU. >>>>>>>>>>> >>>>>>>>>> On Tuesday, March 11, 2025 at 1:11:42 AM UTC-7 Ashley Gullen >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks for the update David - that sounds like a much less >>>>>>>>>>>> disruptive approach than removing it completely. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, 10 Mar 2025 at 19:26, David Adrian <dad...@google.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> To cover the testing use case, we have provided a CLI flag to >>>>>>>>>>>>> enable SwiftShader. This has been in the release notes since >>>>>>>>>>>>> November. If >>>>>>>>>>>>> this is insufficient, we could add an enterprise policy. >>>>>>>>>>>>> >>>>>>>>>>>>> However, rather than attempt a straight removal, we are going >>>>>>>>>>>>> to take a multi-pronged approach to attempt to simultaneously >>>>>>>>>>>>> reduce the >>>>>>>>>>>>> situations where SwiftShader is available, while maintaining >>>>>>>>>>>>> compatibility with devices that require it due to the GPU >>>>>>>>>>>>> blocklist. >>>>>>>>>>>>> >>>>>>>>>>>>> - SwiftShader is already unused on many Mac clients, since >>>>>>>>>>>>> it does not support ARM. We will run an experiment where we >>>>>>>>>>>>> fully remove it >>>>>>>>>>>>> on Mac, where usage is much smaller. We expect this will be >>>>>>>>>>>>> ~fine. >>>>>>>>>>>>> - Similarly, we will try the same on Linux, although this >>>>>>>>>>>>> may not go as well, as there are not a large number of ARM >>>>>>>>>>>>> Linux clients. >>>>>>>>>>>>> - We will experiment with removing the automatic fallback >>>>>>>>>>>>> to SwiftShader after 3 OOMs, limiting it to just the devices >>>>>>>>>>>>> without a GPU >>>>>>>>>>>>> or on the GPU blocklist. This should reduce the attack surface >>>>>>>>>>>>> across the >>>>>>>>>>>>> board, as attackers would be unable to arbitrarily cause >>>>>>>>>>>>> SwiftShader to be >>>>>>>>>>>>> used. In conjunction with this, we'll see if we can leverage >>>>>>>>>>>>> Warp on >>>>>>>>>>>>> Windows. >>>>>>>>>>>>> >>>>>>>>>>>>> If we can get to a state where SwiftShader is off by default >>>>>>>>>>>>> on Mac and Linux, and replaced with Warp on Windows aside from >>>>>>>>>>>>> the CLI >>>>>>>>>>>>> flag, and the fallback is not triggerable by an attacker on >>>>>>>>>>>>> systems with a >>>>>>>>>>>>> "normal" GPU, we'll be in much better shape from a security >>>>>>>>>>>>> standpoint. >>>>>>>>>>>>> >>>>>>>>>>>>> We will update this thread with the progress and results of >>>>>>>>>>>>> these experiments as they roll out. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Mar 3, 2025 at 2:27 PM Rick Byers <rby...@chromium.org> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> +1 that providing temporary enterprise policy exceptions is >>>>>>>>>>>>>> standard >>>>>>>>>>>>>> practice >>>>>>>>>>>>>> <https://www.chromium.org/developers/enterprise-changes/> >>>>>>>>>>>>>> for breaking changes that we predict may have enterprise impact. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Rick >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Mar 3, 2025 at 2:24 PM Erik Anderson < >>>>>>>>>>>>>> erik.a...@microsoft.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Geoff, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My suggestion re: a policy was not to have one that is >>>>>>>>>>>>>>> supported indefinitely. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Many high-risk deprecations have had a policy lasting for, I >>>>>>>>>>>>>>> believe, as little as 3 major version releases. Having such a >>>>>>>>>>>>>>> thing helps >>>>>>>>>>>>>>> mitigate the concern that the risk analysis was way off (which >>>>>>>>>>>>>>> could then >>>>>>>>>>>>>>> mean needing to do a stable respin if your risk analysis was >>>>>>>>>>>>>>> off). If a >>>>>>>>>>>>>>> policy is available, impacted enterprises can quickly >>>>>>>>>>>>>>> self-remediate, >>>>>>>>>>>>>>> report what broke once you flip over the default, and have a >>>>>>>>>>>>>>> little bit >>>>>>>>>>>>>>> more of a window to plan mitigations tied to the removal of the >>>>>>>>>>>>>>> policy >>>>>>>>>>>>>>> (since they’d now be aware of what broke and why). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Erik >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *From:* Ken Russell <k...@chromium.org> >>>>>>>>>>>>>>> *Sent:* Monday, March 3, 2025 10:39 AM >>>>>>>>>>>>>>> *To:* Ashley Gullen <ash...@scirra.com> >>>>>>>>>>>>>>> *Cc:* Geoff Lang <geof...@google.com>; Erik Anderson < >>>>>>>>>>>>>>> erik.a...@microsoft.com>; Rick Byers <rby...@chromium.org>; >>>>>>>>>>>>>>> David Adrian <dad...@google.com>; blink-dev < >>>>>>>>>>>>>>> blin...@chromium.org>; geof...@chromium.org < >>>>>>>>>>>>>>> geof...@chromium.org> >>>>>>>>>>>>>>> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Remove: >>>>>>>>>>>>>>> SwiftShader Fallback >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's feasible, but a significant amount of engineering work >>>>>>>>>>>>>>> that our (Chrome Graphics) team would not be able to prioritize >>>>>>>>>>>>>>> versus >>>>>>>>>>>>>>> other current work that would impact a larger user base. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Ken >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Feb 28, 2025 at 9:45 AM 'Ashley Gullen' via >>>>>>>>>>>>>>> blink-dev <blin...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is it feasible to have SwiftShader (or WARP) run in its own >>>>>>>>>>>>>>> process with a stronger sandbox? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, 28 Feb 2025 at 15:25, Geoff Lang <geof...@google.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hey Erik, Ashley, Rick, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I want to be clear that I think having high WebGL >>>>>>>>>>>>>>> availability is a good thing. I don't think that users with >>>>>>>>>>>>>>> software WebGL >>>>>>>>>>>>>>> have a great experience but it's likely better than no >>>>>>>>>>>>>>> availability, at >>>>>>>>>>>>>>> least for drawing static things. What pushes this over the line >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> warrants this discussion is that JITing code in the GPU process >>>>>>>>>>>>>>> is a huge >>>>>>>>>>>>>>> vulnerability and is a rapidly increasing attack target. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We're investigating WARP as an alternative on Windows. You >>>>>>>>>>>>>>> are right that a large portion of the SwiftShader fallback is >>>>>>>>>>>>>>> on machines >>>>>>>>>>>>>>> with no GPUs (headless or VMs). There are just many unknowns >>>>>>>>>>>>>>> about the >>>>>>>>>>>>>>> quality and security of WARP, it will take a while to be >>>>>>>>>>>>>>> confident in such >>>>>>>>>>>>>>> a change and it still does not resolve the issue of JITing code >>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>> weakly sandboxed GPU process. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regarding corporate policy, I'd much rather have these users >>>>>>>>>>>>>>> fall back in the same way as everyone else and work towards >>>>>>>>>>>>>>> lowering >>>>>>>>>>>>>>> the number of users in this position. It would mean supporting >>>>>>>>>>>>>>> and testing >>>>>>>>>>>>>>> a feature only used by enterprise users when we have no >>>>>>>>>>>>>>> visibility into >>>>>>>>>>>>>>> crashes, bugs or vulnerabilities that they face. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We're also disabling software fallback due to a crashes in >>>>>>>>>>>>>>> the GPU driver (as opposed to blocklisted GPU). Right now any >>>>>>>>>>>>>>> user can >>>>>>>>>>>>>>> fairly easily trigger a GPU crash and fall back to software >>>>>>>>>>>>>>> WebGL which >>>>>>>>>>>>>>> opens up vulnerabilities to all users instead of the 2.7%. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Geoff >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Feb 27, 2025 at 3:28 PM Erik Anderson < >>>>>>>>>>>>>>> erik.a...@microsoft.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The initial message states that SwiftShader primarily covers >>>>>>>>>>>>>>> older Windows devices. Beyond those, there are a non-trivial >>>>>>>>>>>>>>> set of >>>>>>>>>>>>>>> enterprise users that use thin clients to connect to a remote >>>>>>>>>>>>>>> Windows >>>>>>>>>>>>>>> device which is often running in a VM without access to a >>>>>>>>>>>>>>> physical GPU. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example, this applies to the Microsoft Dev Box offering ( >>>>>>>>>>>>>>> https://azure.microsoft.com/en-us/products/dev-box/). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Unfortunately, enterprise clients often turn off telemetry. >>>>>>>>>>>>>>> So, I would assume any UMA-derived metrics to be undercounting >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> population. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It’s likely there are certain line-of-business and/or >>>>>>>>>>>>>>> consumer-oriented sites that have a hard dependency on WebGL to >>>>>>>>>>>>>>> be fully >>>>>>>>>>>>>>> functional. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Have you considered, on Windows, targeting WARP ( >>>>>>>>>>>>>>> https://learn.microsoft.com/en-us/windows/win32/direct3darticles/directx-warp) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> instead? I don’t know if there are other viable alternatives on >>>>>>>>>>>>>>> other OSes, >>>>>>>>>>>>>>> but if the primary impacted clients are Windows perhaps that >>>>>>>>>>>>>>> would be a >>>>>>>>>>>>>>> sufficient mitigation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To help enterprise customers reason about how much this is >>>>>>>>>>>>>>> going to impact them, it would be helpful to have an enterprise >>>>>>>>>>>>>>> policy to >>>>>>>>>>>>>>> control this. This is a common pattern for potentially >>>>>>>>>>>>>>> high-impact changes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In its initial phase, the policy would enable motivated >>>>>>>>>>>>>>> enterprises to forcibly disable SwiftShader as a scream test. >>>>>>>>>>>>>>> And after you >>>>>>>>>>>>>>> switch over the default, it could enable enterprises caught >>>>>>>>>>>>>>> unaware to have >>>>>>>>>>>>>>> some additional window of time to plan mitigations (by >>>>>>>>>>>>>>> re-enabling it via >>>>>>>>>>>>>>> policy) before you proceed with fully deprecating support and >>>>>>>>>>>>>>> remove the >>>>>>>>>>>>>>> policy. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Can you comment on if you plan to add such a policy or, if >>>>>>>>>>>>>>> not, why not? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *From:* 'Ashley Gullen' via blink-dev <blin...@chromium.org> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Sent:* Thursday, February 27, 2025 4:14 AM >>>>>>>>>>>>>>> *To:* Rick Byers <rby...@chromium.org> >>>>>>>>>>>>>>> *Cc:* David Adrian <dad...@google.com>; blink-dev < >>>>>>>>>>>>>>> blin...@chromium.org>; geof...@chromium.org < >>>>>>>>>>>>>>> geof...@chromium.org> >>>>>>>>>>>>>>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Remove: >>>>>>>>>>>>>>> SwiftShader Fallback >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the response Rick, I agree with much of what >>>>>>>>>>>>>>> you've said and I think your views and suggested workarounds >>>>>>>>>>>>>>> are all >>>>>>>>>>>>>>> generally reasonable. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I just realised I previously responded to this thread but >>>>>>>>>>>>>>> only replied to David - for transparency I've copied my >>>>>>>>>>>>>>> previous response >>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can confirm all content made with Construct since about >>>>>>>>>>>>>>> 2018 requires WebGL to work and will show an error message if >>>>>>>>>>>>>>> WebGL is >>>>>>>>>>>>>>> unavailable. I've included a screenshot of the message >>>>>>>>>>>>>>> Construct content >>>>>>>>>>>>>>> published to the web will display when WebGL is not supported, >>>>>>>>>>>>>>> saying >>>>>>>>>>>>>>> "Software update needed", since that has usually been the best >>>>>>>>>>>>>>> advice in >>>>>>>>>>>>>>> that situation in the past. As my previous message says we long >>>>>>>>>>>>>>> ago removed >>>>>>>>>>>>>>> any other fallback and are now likely too dependent on WebGL to >>>>>>>>>>>>>>> feasibly >>>>>>>>>>>>>>> reimplement a canvas2d fallback. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some other thoughts about workarounds/mitigations: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - A swiftshader WASM module would at least give us a >>>>>>>>>>>>>>> workaround, but if that was something like a ~10 MB+ module >>>>>>>>>>>>>>> it would be a >>>>>>>>>>>>>>> very high download overhead which we'd be obligated to >>>>>>>>>>>>>>> include in every >>>>>>>>>>>>>>> Construct export for compatibility >>>>>>>>>>>>>>> - Swiftshader could be removed from insecure origins >>>>>>>>>>>>>>> with little impact to us, and using a permission policy for >>>>>>>>>>>>>>> cross-site >>>>>>>>>>>>>>> iframes should be straightforward to work with >>>>>>>>>>>>>>> - If it helps reduce the attack surface, we could live >>>>>>>>>>>>>>> with SwiftShader support for WebGL 1 only (no WebGL 2) with >>>>>>>>>>>>>>> minimum >>>>>>>>>>>>>>> capabilities (no extensions). >>>>>>>>>>>>>>> - A permission prompt to the user is not ideal but >>>>>>>>>>>>>>> better than nothing, and I imagine it would be tricky to >>>>>>>>>>>>>>> explain to a >>>>>>>>>>>>>>> normal web user though the prompt message (and makes >>>>>>>>>>>>>>> obtaining a WebGL >>>>>>>>>>>>>>> context async...) >>>>>>>>>>>>>>> - Regarding getting WebGL to work on more devices, as I >>>>>>>>>>>>>>> mentioned in my previous message, reviewing the GPU >>>>>>>>>>>>>>> blocklist to re-enable >>>>>>>>>>>>>>> WebGL for older devices if drivers have been updated or >>>>>>>>>>>>>>> workarounds for >>>>>>>>>>>>>>> issues can be found would help reduce the number of devices >>>>>>>>>>>>>>> subject to >>>>>>>>>>>>>>> SwiftShader. Being able to enable at least WebGL 1 will >>>>>>>>>>>>>>> still help with >>>>>>>>>>>>>>> Construct content. >>>>>>>>>>>>>>> - If a software fallback can be securely implemented for >>>>>>>>>>>>>>> WebGPU, Construct has a WebGPU renderer too now so that >>>>>>>>>>>>>>> would give us a >>>>>>>>>>>>>>> workaround (and potentially for any other WebGL content - >>>>>>>>>>>>>>> AFAIK many widely >>>>>>>>>>>>>>> used libraries like three.js now either support WebGPU or >>>>>>>>>>>>>>> are working on it) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for the consideration all. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Copy of my previous message: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OK, thanks for the information. I just want to point out >>>>>>>>>>>>>>> that even stopping WebGL content for only 2.7% of users is >>>>>>>>>>>>>>> still >>>>>>>>>>>>>>> potentially very disruptive. Consider a web game on Poki that >>>>>>>>>>>>>>> requires >>>>>>>>>>>>>>> WebGL and gets a million players. With this change, now 27,000 >>>>>>>>>>>>>>> users will >>>>>>>>>>>>>>> see a "WebGL not supported" error message. That's then >>>>>>>>>>>>>>> potentially a huge >>>>>>>>>>>>>>> number of new support requests to deal with. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Can you share the number for Construct about what >>>>>>>>>>>>>>> percentage of your users are using the SwiftShader fallback? >>>>>>>>>>>>>>> Again, our >>>>>>>>>>>>>>> numbers indicate that these are primarily older Windows >>>>>>>>>>>>>>> workstations. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For the Construct editor itself, it is around 3%, so that >>>>>>>>>>>>>>> seems in line. But the key point here is that Construct is >>>>>>>>>>>>>>> middleware: it >>>>>>>>>>>>>>> is a tool our users develop web games in and then publish >>>>>>>>>>>>>>> independently of >>>>>>>>>>>>>>> us. It is much more important that WebGL works for players of >>>>>>>>>>>>>>> those games >>>>>>>>>>>>>>> than it does for Construct itself. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lots of people use older Windows workstations. We've had >>>>>>>>>>>>>>> issues before where for example a graphics driver bug affecting >>>>>>>>>>>>>>> WebGL 1 >>>>>>>>>>>>>>> caused a great deal of trouble in a South American market, even >>>>>>>>>>>>>>> though I >>>>>>>>>>>>>>> suspect it only affected a small percentage of devices - see >>>>>>>>>>>>>>> https://issues.chromium.org/issues/40941645 which was never >>>>>>>>>>>>>>> resolved. There are probably places in the world where there >>>>>>>>>>>>>>> are large >>>>>>>>>>>>>>> numbers of people using older Windows workstations. I fear that >>>>>>>>>>>>>>> pulling >>>>>>>>>>>>>>> WebGL support from those devices may result in much higher >>>>>>>>>>>>>>> numbers of >>>>>>>>>>>>>>> unsupported users, and many more support requests, in the >>>>>>>>>>>>>>> specific markets >>>>>>>>>>>>>>> where such devices are common. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Is there anything that can be done to mitigate this change? >>>>>>>>>>>>>>> Given SwiftShader allowed WebGL to be considered ubiquitous for >>>>>>>>>>>>>>> many years, >>>>>>>>>>>>>>> engines like Construct long ago removed any fallback for >>>>>>>>>>>>>>> systems that do >>>>>>>>>>>>>>> not support WebGL; we moved forward assuming we could rely on >>>>>>>>>>>>>>> WebGL, and so >>>>>>>>>>>>>>> now it's probably infeasible to bring back any fallback as we >>>>>>>>>>>>>>> have too many >>>>>>>>>>>>>>> key features that fundamentally require WebGL. Could >>>>>>>>>>>>>>> SwiftShader be adapted >>>>>>>>>>>>>>> to not use JIT? Could some other fallback be found? Could the >>>>>>>>>>>>>>> GPU blocklist >>>>>>>>>>>>>>> be revised to enable WebGL on as many older devices as possible? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think the number of affected users should be <1% to >>>>>>>>>>>>>>> minimise the impact from such a change. At web scale 2.7% is >>>>>>>>>>>>>>> still a lot. >>>>>>>>>>>>>>> Perhaps with revising the GPU blocklist and adding more >>>>>>>>>>>>>>> workarounds this is >>>>>>>>>>>>>>> feasible. I fear if this goes ahead without any mitigation, it >>>>>>>>>>>>>>> will cause a >>>>>>>>>>>>>>> great deal of trouble and is exactly the kind of thing sceptics >>>>>>>>>>>>>>> of the web >>>>>>>>>>>>>>> will bring up to say that web technology sucks, browsers can't >>>>>>>>>>>>>>> be trusted, >>>>>>>>>>>>>>> and people should just develop desktop games instead. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, 25 Feb 2025 at 22:31, Rick Byers < >>>>>>>>>>>>>>> rby...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sorry for the delay from API owners, as discussed on chat >>>>>>>>>>>>>>> the chromestatus entry wasn't set up properly to request API >>>>>>>>>>>>>>> owner review >>>>>>>>>>>>>>> (now fixed). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a tricky one indeed (thanks for your input Ashley!). >>>>>>>>>>>>>>> It looks like >>>>>>>>>>>>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4026> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WebGL is used on about 20% of page loads, so 2.7% of that is >>>>>>>>>>>>>>> ~0.5% of page >>>>>>>>>>>>>>> loads which is very high risk according to our rules of >>>>>>>>>>>>>>> thumb >>>>>>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.mqfkui78vo5z> >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course that's an upper-bound, how many will have a >>>>>>>>>>>>>>> fallback? One option would be to collect some UKM data for >>>>>>>>>>>>>>> SwiftShader >>>>>>>>>>>>>>> usage and review a random ~50 sites to observe the user >>>>>>>>>>>>>>> experience in >>>>>>>>>>>>>>> practice. That could give us a better sense of what the real >>>>>>>>>>>>>>> user impact >>>>>>>>>>>>>>> would likely be. Or Maybe Ashley can give us some examples of >>>>>>>>>>>>>>> some web >>>>>>>>>>>>>>> games just to confirm they indeed go from being playable to >>>>>>>>>>>>>>> unplayable without swiftshader on some specific devices? David, >>>>>>>>>>>>>>> do you have >>>>>>>>>>>>>>> a device yourself you can test with that doesn't support GPU >>>>>>>>>>>>>>> WebGL? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regardless, unless sites have been really good about almost >>>>>>>>>>>>>>> always falling back somehow, I suspect we'll find that there's >>>>>>>>>>>>>>> enough >>>>>>>>>>>>>>> end-user impact to make this a high-risk change (but I could be >>>>>>>>>>>>>>> convinced >>>>>>>>>>>>>>> otherwise such as via a thorough UKM analysis). In which case >>>>>>>>>>>>>>> then we could >>>>>>>>>>>>>>> start working through our playbook for a phased plan for risky >>>>>>>>>>>>>>> breaking >>>>>>>>>>>>>>> changes. Not unlike what we did for flash removal >>>>>>>>>>>>>>> <https://www.chromium.org/flash-roadmap/>, or WebSQL >>>>>>>>>>>>>>> <https://developer.chrome.com/blog/deprecating-web-sql> (both >>>>>>>>>>>>>>> big security benefit but big web compat risk). For example: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Explore whether we can build swiftshader into a wasm >>>>>>>>>>>>>>> module that sites can use as a (probably even slower) >>>>>>>>>>>>>>> fallback themselves. >>>>>>>>>>>>>>> This turned out to be the key to making WebSQL deprecation >>>>>>>>>>>>>>> tractable. In >>>>>>>>>>>>>>> general our policy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit?tab=t.0#heading=h.x5bhg5grhfeo> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> is that we don't take functionality away that developers >>>>>>>>>>>>>>> can't replace with >>>>>>>>>>>>>>> some other substitute except in pretty extreme >>>>>>>>>>>>>>> circumstances. >>>>>>>>>>>>>>> - Prompt the user on whether or not to enable it >>>>>>>>>>>>>>> per-origin (like a permission) >>>>>>>>>>>>>>> - Put 3p usage behind a permission policy so the >>>>>>>>>>>>>>> top-level site has to opt-in to allow 3p iframes to use >>>>>>>>>>>>>>> swiftshader >>>>>>>>>>>>>>> - Rely on some heuristics, (perhaps crowd-sourced >>>>>>>>>>>>>>> signals) to try to find a sweet spot in the safety vs. >>>>>>>>>>>>>>> functionality >>>>>>>>>>>>>>> tradeoff space. We did this for flash initially with things >>>>>>>>>>>>>>> like blocking >>>>>>>>>>>>>>> it for very small canvases. >>>>>>>>>>>>>>> - Anything we can do to make WebGL work on a larger set >>>>>>>>>>>>>>> of devices? >>>>>>>>>>>>>>> - Probably lots of other ideas that aren't occurring to >>>>>>>>>>>>>>> me right now, more examples in bit.ly/blink.compat. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On the other side of the equation, API owners can be >>>>>>>>>>>>>>> convinced to accept more compat risk the more significant the >>>>>>>>>>>>>>> security >>>>>>>>>>>>>>> benefits are. Are there more details you can share? Such as: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - Are we confident that an attacker can only trigger >>>>>>>>>>>>>>> swiftshader on somewhere around 3% of users (vs. some knob >>>>>>>>>>>>>>> which can force >>>>>>>>>>>>>>> it to be used on a larger fraction)? To what extent do we >>>>>>>>>>>>>>> have reason to >>>>>>>>>>>>>>> believe that the vulnerable population size is large enough >>>>>>>>>>>>>>> to be a >>>>>>>>>>>>>>> plausible target for attackers? Is there anything we can do >>>>>>>>>>>>>>> to make the >>>>>>>>>>>>>>> vulnerable user base more reliably contained? >>>>>>>>>>>>>>> - How does swiftshader compare to other areas in terms >>>>>>>>>>>>>>> of the number of vulnerabilities we've found in practice? >>>>>>>>>>>>>>> Are there any >>>>>>>>>>>>>>> reports of ITW exploits of it? It looks like >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://chrome-commit-tracker.arthursonzogni.com/cve/reward_per_components?start=2019-12-27&end=2025-02-25> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> since 2020 SwiftShader has been about 8% of Chrome's VRP >>>>>>>>>>>>>>> spend - that seems >>>>>>>>>>>>>>> quite significant to me, but probably not in the top 5 areas >>>>>>>>>>>>>>> of concern. >>>>>>>>>>>>>>> This was obviously key to the immense cost and pain of Flash >>>>>>>>>>>>>>> removal - we >>>>>>>>>>>>>>> kept having severe security incidents in practice. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So assuming Ashley and I are right that this isn't likely to >>>>>>>>>>>>>>> be easy, that means it's likely quite a lot of work to attempt >>>>>>>>>>>>>>> to phase-out >>>>>>>>>>>>>>> SwiftShader in a responsible fashion. But with luck maybe we >>>>>>>>>>>>>>> can find a >>>>>>>>>>>>>>> first step that is a good cost-benefit tradeoff (like putting >>>>>>>>>>>>>>> 3P usage >>>>>>>>>>>>>>> behind a permission prompt)? Or maybe it's just a better >>>>>>>>>>>>>>> cost-benefit >>>>>>>>>>>>>>> tradeoff to invest in other areas which pose a threat to a >>>>>>>>>>>>>>> greater number >>>>>>>>>>>>>>> users (hardening ANGLE perhaps)? But of course I will defer to >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> judgement of security and GPU experts like yourself on that >>>>>>>>>>>>>>> question, I'm >>>>>>>>>>>>>>> happy to consult and support if you want to invest in a plan >>>>>>>>>>>>>>> that API >>>>>>>>>>>>>>> owners can approve. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Rick >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Feb 19, 2025 at 2:48 PM 'David Adrian' via >>>>>>>>>>>>>>> blink-dev <blin...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > 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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It does, not it comes from Chrome's metrics system. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Does Google have their own internal data about the usage >>>>>>>>>>>>>>> of SwiftShader? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It is the 2.7% number. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > 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. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > 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 you share the number for Construct about what percentage >>>>>>>>>>>>>>> of your users are using the SwiftShader fallback? Again, our >>>>>>>>>>>>>>> numbers >>>>>>>>>>>>>>> indicate that these are primarily older Windows workstations. >>>>>>>>>>>>>>> Notably, >>>>>>>>>>>>>>> SwiftShader is not used at all on mobile. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > 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? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. The GPU process is shared between all sites, whereas >>>>>>>>>>>>>>> the V8 JIT is per-site. This means compromising the GPU process >>>>>>>>>>>>>>> can be >>>>>>>>>>>>>>> enough to bypass site isolation protections with a single bug. >>>>>>>>>>>>>>> Additionally, V8 bugs can be reliably patched in the browser, >>>>>>>>>>>>>>> whereas >>>>>>>>>>>>>>> SwiftShader "bugs" can be user-mode graphics driver bugs that >>>>>>>>>>>>>>> are simply >>>>>>>>>>>>>>> more exposed via SwiftShader than they would be otherwise. In >>>>>>>>>>>>>>> this case, >>>>>>>>>>>>>>> the browser can't patch the bug because it's in the driver. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thursday, February 13, 2025 at 12:12:07 PM UTC-5 >>>>>>>>>>>>>>> ash...@scirra.com wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>> blin...@chromium.org> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> dad...@google.com, geof...@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 milestones >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shipping 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+...@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+...@chromium.org. >>>>>>>>>>>>>>> To view this discussion visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%40chromium.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c5131675-dff4-4aa0-8e84-4cdc373e3035n%40chromium.org?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+...@chromium.org. >>>>>>>>>>>>>>> To view this discussion visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73jWBkuxvj%3DDDXmEQNwLfCa_uV5OZZ5nZJRj9ZMgP9yk7Q%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+...@chromium.org. >>>>>>>>>>>>>>> To view this discussion visit >>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%40mail.gmail.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAABs73hYs9O-2hdmfn37fQb-U-8m_-08i3Qg9dkUhKNQQvNLSg%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/d9f96e93-cdb3-46bb-a7a6-906b316707d3n%40chromium.org.
