3eb3eed8cf
1609: [Vulkan] Initialize wgpu objects from raw handles r=kvark a=zarik5 **Connections** This PR is a successor of https://github.com/gfx-rs/gfx/pull/3762 **Description** The `handle_is_external` flag mechanism was not enough to ensure safety, when for example the Instance is wrapped in `Arc<>` and a library cannot keep track of all its clones. This is the case with the bevy render rewrite. The solution was to let wgpu be in charge of destroying the handles, but it also has to keep a reference to a "drop guard" which is always dropped after the handle is destroyed. For the OpenXR integration, this drop guard will be `xr::Instance`. For now this is just a proof of concept. Only instance creation is handled, and there is even type error in `wgc::Instance::from_hal()`. I have a few concerns: * Is it ok to expose `hal::Instance` from the wgpu crate? Or should the user pass all the parameters so `hal::Instance` can be constructed internally? This second options is more disruptive, since the wgpu-types crate would need to import all platform-specific crates to define the structure/enum to hold the raw handles. * Without counting the call to create the `hal::Instance`, there are 4 indirection calls to save the raw instance. Can this be optimized in any way? Do you think it is possible to merge wgpu-hal into wgpu-core? This could help with reducing the distance from the surface level API to the platform specific APIs even more. **Testing** Vulkan/Android (Oculus Quest) using [this sample](https://github.com/zarik5/openxrs/blob/wgpu-test/openxr/examples/vulkan.rs). Co-authored-by: Riccardo Zaglia <riccardo.zaglia5@gmail.com> |
||
|---|---|---|
| .. | ||
| examples/halmark | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
wgpu-hal is an explicit low-level GPU abstraction powering wgpu-core. It's a spiritual successor to gfx-hal, but with reduced scope, and oriented towards WebGPU implementation goals.
It has no overhead for validation or tracking, and the API translation overhead is kept to the bare minimum by the design of WebGPU. This API can be used for resource-demanding applications and engines.
Usage notes
All of the API is unsafe. Documenting the exact safety requirements for the
state and function arguments is desired, but will likely be incomplete while the library is in early development.
The returned errors are only for cases that the user can't anticipate, such as running out-of-memory, or losing the device. For the counter-example, there is no error for mapping a buffer that's not mappable. As the buffer creator, the user should already know if they can map it.
The API accept iterators in order to avoid forcing the user to store data in particular containers. The implementation doesn't guarantee that any of the iterators are drained, unless stated otherwise by the function documentation. For this reason, we recommend that iterators don't do any mutating work.
Debugging
Most of the information in https://github.com/gfx-rs/wgpu/wiki/Debugging-wgpu-Applications still applies to this API, with an exception of API tracing/replay functionality, which is only available in wgpu-core.