we will add an url option to force it so that you can benchmark it. I’ll ping you when it’s in prod.
That message does need rework, you’re right. We’ll try to make a better message.
As you can see in this Forum post, most of use case is:
- blacklisted gpus
- repeated “webgl crash”
In both case, what user wants is re-enabling the GPU, not going SwiftShader route.
Doing like we do now allows us to solve user problem. (which is re-enabling their GPU)
Use case of swiftShader for us would be with GPU we cannot support.
Those are very exotic kind of GPU, like those Vivante GPUs, with their “max_fragment_uniforms: 6”.
For that use case, we would need a guaranteed way to enable SwiftShader on demand though when we consider the GPU “unacceptable”. I don’t think there is a way from inside js for now ?
(not a cli switch or chrome flags, but a was to explicitly request a software webgl context)
When we tried swiftShader, the resulting user experience was very different than when using GPU (even on our very high end developer’s CPUs):
- near freeze of all the os desktop
- high input latency
- near instant cpu fans to the max
- laptop battery going out very fast