Add better async support for wgpu-native

[almarklein]

Relates to #391

This PR adds support for true async behavior for wgpu-native, to the extend that this is implemented in wgpu-native.

What this does

• Implements WgpuWaitable as a basic component to use for async methods.
• Apply it to the async methods where possible.

Notes

• The request_adapter() and request_device() are not really async in native (only in wasm/remote implementations?)
• The wgpuDeviceCreateRenderPipelineAsync is not yet implemented 🤷
• Amongst the stuff that we have not yet implemented are also a few async ones.
• So the only real async version is buffer.map_async().
• The API for async methods in webgpu.h is in the process of being changed, so we will have to modify the code later, but it will likely be good that we have our basics in place. See below.

The new upcoming wgpu-native API

(Also added this info to #391)

In the new API, wgpu-native methods that are async will return a "GPUFuture". This future can be polled (similar to what we do now), and there will be a call to wait for the future: wgpuInstanceWaitAny(). The latter, however, won't help make it async in Python. There is an idea for an API to expose OS-level constructs so proper integration with an event loop is possible.

• Docs: https://webgpu-native.github.io/webgpu-headers/Asynchronous-Operations.html
• Design document: https://docs.google.com/document/d/1qJRTJRY318ZEqhK6ryw4P-91FumYQfOnNP6LpANYy6A/edit#heading=h.vrujxb8hydu

[almarklein]

Is there no way to register a callback on is_done? That way you could get rid of the busy loop.

I'm answering this in the mean comments, since I want to be able to read back what I write later 😄

Good question. The short answer is no. Such an API would require wgpu-native to run a separate thread or something, which will introduce other complications, which is why they did not go this route.

The longer answer: in (probably) the next release of wgpu-native, we can use wgpuInstanceProcessEvents() which will fire the callbacks when they're done. So as long as we make sure that method is called periodically, we can kindof have that. For example by using the trick that asyncio.sleep uses (https://github.com/python/cpython/blob/9ce90206b7a4649600218cf0bd4826db79c9a312/Lib/asyncio/tasks.py#L688-L705):

• We create and return an asyncio.Future
• In the callbacks, we can do loop.call_soon(set_that_features_result)

One problem with the above: it'd bind us to asyncio. We can investigate whether a framework agnostic method is possible.

But in the end, the current solution works pretty well. Yes, it turns your CPU to 100%, but the wait time for these functions is typically very short, and other async tasks can run while this happens.

BTW: I also added a section in the top comment on the upcoming API, with links to docs that explain it.

[almarklein]

I am updating the examples so cube.py can touch buffer.map_async(), but it needs some refactoring so I'll post that in a separate PR.

[almarklein]

Oh, I have a codegen issue to fix before this can be merged.

[Korijn]

Well, good to hear some improvement is coming later on. Futures are designed to solve this problem specifically. All we need is a callback to resolve the future. :)