webgpu: Use WGPU poller thread for poll_all_devices

[sagudev]

As discussed https://servo.zulipchat.com/#narrow/stream/263398-general/topic/ipc_channel, firefox will also switch to something similar in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=1870699.

In future we could make thread per device, but that would require hashmap for Pollers.

Fastgame still works: https://sagudev.github.io/briefcase/fastgame.html

try run: https://github.com/sagudev/servo/actions/runs/9051091523/job/24867638272

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• There are tests for these changes in WebGPU CTS

[sagudev]

Timings are more sane now (we actually outperform firefox on onSubmittedWorkDone tests due to https://bugzilla.mozilla.org/show_bug.cgi?id=1870699):

EDIT: According to measurements on my computer we are also faster than chromium (edge) on onSubmittedWorkDone tests (tested edge vs. servo on my win11 machine).

[sagudev]

Some flakes that do occur but rarely (sometimes they are stable, other times they simply do not happen):

• CRASH [expected OK] /_webgpu/webgpu/cts.https.html?q=webgpu:api,validation,buffer,mapping:mapAsync,state,destroyed:*
  with:

called `Result::unwrap()` on an `Err` value: Destroyed (thread WGPU poller, at components/webgpu/wgpu_thread.rs:112)

(this is actually our fault as we do not handle this situation).

• ERROR /_webgpu/webgpu/cts.https.html?q=webgpu:api,validation,buffer,mapping:mapAsync,state,mappingPending:* subtest: TIMEOUT instead of FAIL (I have no idea about this one, but once implemented correctly it should work).
• TIMEOUT [expected OK] /_webgpu/webgpu/cts.https.html?q=webgpu:api,operation,compute,basic:large_dispatch:* (deadlock in wgpu: [core] deadlock between poll_all_devices and queue_submit gfx-rs/wgpu#5695)

[gterzian]

LGTM, with some nits and perhaps one refactoring.

[gterzian]

(this is actually our fault as we do not handle this situation).

File an issue for this one? Seems like we can catch the destroy error and send an error back to script?

[sagudev]

(this is actually our fault as we do not handle this situation).

File an issue for this one? Seems like we can catch the destroy error and send an error back to script?

Done #32277

[gterzian]

LGTM