Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_0f5df16

Does it have to be as vague and general as "failIfMajorPerformanceCaveat" if what we mean here is really "allowSoftware"?

It can and has in the past been used for other things. The WebGL spec calls out a case that actually occurred:

An implementation might require reading back the framebuffer from GPU memory to system memory before compositing it with the rest of the page, significantly reducing performance.

I find this flag to be way too broad if it wants to gate against the CPU readback for swapchains. All it does is copying a screen-sized portion of data 2 times more than necessary. It's totally irrelevant for GPU-intensive applications like TF.js. It mostly affects latency-sensitive applications like VR.

This is much different from "I'm a lavapipe driver" or "Ima WARP" device, where you know you just can't do much.

I thought about this further last night and I think I agree, since WebGPU is more general than WebGL and no single emulated path like that would constitute a major performance caveat for the whole device. Probably we should just constrain this to software emulation. To discuss.

I'm not sure the details of why the CPU readback is/was such a performance problem with WebGL, but it may have been GPU->gpu process->content process->..., or copies may have been blocking/bottlenecking other work.

I'm really conflicted about failIfMajorPerformanceCaveat, especially since we're running into issues in-the-wild for WebGL on even on prominent apps like Google Maps. (where 3d-mode doesn't work if failIfMajorPerformanceCaveat kicks in) We've also seen libraries where people don't include fallbacks, and so leave users out in the cold unless users fiddle with prefs.

I generally feel now that failIfMajorPerformanceCaveat gives over too much discretion to apps rather than the user or user agent.

I think a better approach would be to have a readonly attribute that gives a cpuEmulated hint, and skip any presentationPerformanceCaveat, since it's not really actionable information for the App.

cpuEmulated is more actionable though, since an app might choose to load a WebGL fallback. I think this is subtly but importantly different than a fail-if-caveat solution, since it requires Apps to do /more/ work to reject caveated implementations, whereas what we've seen with failIfMajorPerformanceCaveat choices by Apps is too user-hostile.

Just for background information, which configurations are browsers planning to ship that would enable this kind of flag?

Instead of encouraging web content to fall back from hardware WebGPU to software WebGPU, shouldn't we be encouraging web content to fall back from hardware WebGPU to hardware WebGL instead?

WebGL is a critical part of the web platform. It isn't going away.

As mentioned on the call, supporting both WebGPU and WebGL is a huge complication for an app. I expect many applications to be developed purely for WebGPU, and being able to run even on incompatible devices would be a big plus for them.

Another case is - CI. If I'm working on a library on top of WebGPU, and I want to test on CI, with "allowSoftware" I don't need to opt into CI park with HW accelerated machines and custom configuration. Ecosystem wins from this.

P.S. I want Firefox to be able to run on software. We already have a similar approach with WebRender on software-GL, and we are happy with it.

Instead of encouraging web content to fall back from hardware WebGPU to software WebGPU, shouldn't we be encouraging web content to fall back from hardware WebGPU to hardware WebGL instead?

What could we do to encourage that? Not ship software implementations of WebGPU at all? I don't think that's a good option.

Developers who want to fall back to hardware WebGL will figure it out quickly - they've done this with WebGL 2->1 fallback in the past with no problem. As long as we provide them the necessary signal.

Honestly we never did a great job with webgl2->webgl1 fallback. failIfM[...] is close but not really what you want for this case.

I think what our users want here is a relative comparison between the new and old API.
Strawman: gpu.slowerThanWebgl2 and webgl2.slowerThanWebgl1 and webgl.slowerThanCanvas2d
(canvas.slowerThanDom?)

I think the group agreed to not pursue this direction. Can this PR be closed?

I think we could still end up choosing a direction of "allowSoftware" which is almost the same as this. But we can centralize the discussion on #1439

I think what we agreed upon is this, but possibly with some refactoring.

@kainino0x I think we agreed on allowSoftware, not the performance caveat.

Isn't it almost the same thing?

I guess it's less confusing to make this a new PR.