I expect the name will change once we add a similar option in WebGPU (maybe?) The IDL is the following:

Promise<GPUAdapter> requestAdapter(optional GPURequestAdapterOptions options = {});

So maybe WGPUAdapterDescriptor shoud be WGPURequestAdapterOptions? I expect we'll have direct adapter creation or a way to list them all eventually and want to free the name WGPUAdapterDescriptor for that use.

Thank you for looking at this promptly!

My own's main concern here is that it doesn't handle the case where a user wants to present to multiple surfaces with the same adapter. Even if unlikely, there is a way for us to cover that - via pNext chain: we could define a struct where the user provides the WGPUSurface to the pNext chain of AdapterDescriptor, and then the user could pass any number of them.

Do you think it's worth going that direction now?

I expect the name will change once we add a similar option in WebGPU (maybe?)

That's a tough question that we may need to revisit once we make any progress on HW-accelerated swapchains (which we don't have in Gecko's WebGPU yet). In the worst case it will be an extension that adds the extra field.

So maybe WGPUAdapterDescriptor shoud be WGPURequestAdapterOptions?

Yeah, we should update that, just not in this PR.

In WebGPU GPUCanvasContext.{configureSwapChain,getSwapChainPreferredFormat} both require a device to be passed in. We'll reconfigure the canvas to work with whatever adapter you're using. So there's a dependence graph:

• swap chain -> device -> adapter
• swap chain -> canvas context -> canvas

I guess WGPUSurface is different because it represents an actual window that's already been created that we can't reconfigure. This makes the dependence graph:

• swap chain -> surface
• device -> adapter -> surface

which on native makes sense if I want to pick the adapter that's native to a window (if e.g. a window is on the laptop display). But if you wanted to make a surface that's compatible with an adapter (e.g. the discrete adapter), wouldn't you want:

• swap chain -> surface -> adapter
• device -> adapter

?

@kainino0x I'm not aware of any workflow that would involve creating a surface for an adapter. People create a Window and want to render into it somehow. Often, the GPU rendering is only partially using the window, there can be other UI/logic/etc, and thus the graphics subsystem don't get to participate in window creation.

Is a window tied to a particular hardware adapter? If yes, I can imagine you'd want to make sure you create the window on the discrete adapter regardless of which display it's on, so that the OS level compositor can do its best job compositing content from multiple hardware adapters.

Window is tied to a screen, screen may be tied to an adapter. Since the user can at any point move the window to a different screen, you don't really control whether you can always use discreet GPU. IIRC, apps just put a window on a "default" (or "main") screen and work with adapters that are available, up until the "surface lost" or "out of date" events.

At least on Windows and Mac, you can definitely rely on a window from one hw adapter being composited to all displays seamlessly and without any kind of surface loss event (though you can always detect display switch and reinit on the right adapter). I don't know about Linux though.

This is basically resolved, merging now.