I'm not sure exactly how to read this file but it looks right to me: disable "AllowSoftwareGLFallbackDueToCrashes" disable "AllowSwiftShaderFallback" enable "AllowD3D11WarpFallback"
How are you testing? You can use "--enable-features=AllowD3D11WarpFallback --disable-features=AllowSoftwareGLFallbackDueToCrashes,AllowSwiftShaderFallback". Other command line arguments can interfere too, things like "--use-angle=swiftshader" would force it back on. Geoff On Fri, Aug 22, 2025 at 12:33 AM Fred Potter <fpot...@gmail.com> wrote: > Hi Folks, > > I tried to pull the experiment setup for SwiftShaderDeprecation, and > wanted to confirm the behavior with you all to make sure I'm parsing it > right -- > https://gist.github.com/fpotter/48395681a0ec900a27e019be9e41b323 > > By my read, it looks like when SwiftShader is disabled for a Windows user, > they'll always be opted into the WARP fallback at the same time. Is that > right? > > I've been trying to test myself on v139 on Windows (in Stable, Beta, and > Canary), but so far I've been unlucky and continue to get SwiftShader > according to chrome://gpu. > > Thanks! > Fred > > > > > On Thursday, August 14, 2025 at 7:22:59 AM UTC-7 Geoff Lang wrote: > >> No plans, unfortunately. Chromium isn't set up to easily share resources >> between different GL drivers right now. >> >> On Tue, Jul 29, 2025 at 2:00 PM PhistucK <phis...@gmail.com> wrote: >> >>> I am just curious... Are there any plans to add WebGL 2 software >>> rendering support/fallback? My machine can use fewer and fewer WebGL-based >>> websites because they use WebGL 2... >>> >>> >>> ☆*PhistucK* >>> >>> >>> On Wed, Jul 9, 2025 at 4:35 PM 'David Adrian' via blink-dev < >>> blin...@chromium.org> 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+...@chromium.org. >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2cfb0848-03a1-4cd6-9c09-7ad8026a9f3dn%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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BPGBXt7k-DPP%3DTiPBkLyyzBdEcLx0RjzSNjLjRStCDtL81b5Q%40mail.gmail.com.
