Status of dual-GPU support on Windows?

109 views
Skip to first unread message

Ken Russell

unread,
Aug 11, 2023, 6:11:57 PM8/11/23
to graphics-dev
Hi Chromium graphics developers,

What is the expected status of dual-GPU support on Windows? It looks like the code expects it to work now that the EGLDualGPURendering flag which Jonah added is available:

but it's off by default on Windows:

Wondering whether the large amount of SharedImage work recently has made this "just work". Some automatic surface copies between GPUs to different D3D11 textures per D3D11 device would need to be done behind the scenes; not sure if this is implemented.

If it's still in progress, do you have a pointer to a bug?

Thanks,

-Ken

Sunny Sachanandani

unread,
Aug 11, 2023, 6:38:46 PM8/11/23
to Ken Russell, graphics-dev
Recently, we've made Chrome's D3DImageBacking aware of the D3D11 device it's being used on per access. This was done for interop between any of Graphite/Dawn/D3D11, WebGL/ANGLE/D3D11, or WebGPU/Dawn/D3D12 (and WebGPU/Dawn/D3D11 in the future if we want that). We could extend it to support devices on different adapters with some work.

IIUC the current general solution for cross-adapter sharing with D3D11 is copying through system memory using staging textures (not sure if we need 1 or 2 staging textures - depends on whether staging textures can be shared resources). However, there are cases where we could eliminate a copy by mapping a GPU texture on the integrated adapter (on UMA systems) and then copying from that to a staging texture - the feature is called "mappable default textures" which instructs the driver to use a non-swizzled standard layout for such textures - we already use this for OneCopyCanvasCapture (example).

We'll also need to make sure we use D3DImageBackings for all the cases where we need interop - that means WebGL and WebGPU back buffers as well as CanvasResourceProvider textures at the very least. Video textures already use D3D11 textures or shared memory so assuming we always copy via system memory, we shouldn't need extra resource sharing shenanigans for these (although we might need it for Graphite and WebGL/WebGPU interop anyway).
Reply all
Reply to author
Forward
0 new messages