wgpuInstanceWaitAny panics at runtime (src/unimplemented.rs:230). The broader WGPUFuture machinery is also stubbed out — all async APIs return a null future (id 0), and instance capabilities report timedWaitAnyEnable: false.
wgpuInstanceProcessEvents works fine and callbacks do fire during poll, so the workaround is a poll loop with a flag:
// standard (works on Dawn)
callbackInfo.mode = WGPUCallbackMode_WaitAnyOnly;
wgpuBufferMapAsync(buffer, ...callbackInfo);
wgpuInstanceWaitAny(instance, 1, &futureInfo, UINT64_MAX);
// wgpu-native workaround
callbackInfo.mode = WGPUCallbackMode_AllowProcessEvents;
wgpuBufferMapAsync(buffer, ...callbackInfo);
while (!done) {
wgpuDevicePoll(device, true, NULL);
}
This works but forces anyone targeting both Dawn and wgpu-native into #ifdef branches for every async operation (buffer mapping, submitted work done, etc). We hit this in MapLibre Native's WebGPU backend.
I realize the hard part is that wgpu-core doesn't have a future-multiplexing primitive — it has per-device device_poll and poll_all_devices but nothing like "wait until any of N futures completes." So this probably needs either a future registry layer in wgpu-native on top of the existing polling, or upstream support in wgpu-core.
Related: #510 (user hitting the panic), webgpu-headers #199 (the spec-level design for WGPUFuture, now resolved).
wgpuInstanceWaitAnypanics at runtime (src/unimplemented.rs:230). The broaderWGPUFuturemachinery is also stubbed out — all async APIs return a null future (id 0), and instance capabilities reporttimedWaitAnyEnable: false.wgpuInstanceProcessEventsworks fine and callbacks do fire during poll, so the workaround is a poll loop with a flag:This works but forces anyone targeting both Dawn and wgpu-native into
#ifdefbranches for every async operation (buffer mapping, submitted work done, etc). We hit this in MapLibre Native's WebGPU backend.I realize the hard part is that
wgpu-coredoesn't have a future-multiplexing primitive — it has per-devicedevice_pollandpoll_all_devicesbut nothing like "wait until any of N futures completes." So this probably needs either a future registry layer in wgpu-native on top of the existing polling, or upstream support in wgpu-core.Related: #510 (user hitting the panic), webgpu-headers #199 (the spec-level design for WGPUFuture, now resolved).