Low level interop with Vulkan backend #3762
Conversation
|
I see some fields of the backend structs |
|
For now I remove |
src/backend/vulkan/src/lib.rs
Outdated
| /// `raw_instance` must be manually destroyed *after* gfx-hal Instance has been dropped. | ||
| pub unsafe fn from_raw( | ||
| #[cfg(not(feature = "use-rtld-next"))] entry: Entry, | ||
| #[cfg(feature = "use-rtld-next")] entry: EntryCustom<()>, |
There was a problem hiding this comment.
we should probably use the fact that type Entry = EntryCustom<Arc<Library>>. So the only thing different between use-rtld-next and not is the generic parameter (which we can typedef somewhere).
There was a problem hiding this comment.
Great idea! Using cfg-gated parameters was also confusing rust-analyzer.
There was a problem hiding this comment.
I preferred using a typedef on Entry, typedef-ing only the type argument felt like splitting the type in half.
|
@kvark Thank you! The work here is not finished, I'm developing this API while working on a minimum example for integration with OpenXR. I have to work around the missing support of multiview in gfx-hal, which should be handled in another PR. |
| pub unsafe fn image_view_from_raw( | ||
| &self, | ||
| raw_image: vk::Image, | ||
| view_type: vk::ImageViewType, | ||
| format: format::Format, | ||
| swizzle: format::Swizzle, | ||
| usage: image::Usage, | ||
| range: image::SubresourceRange, | ||
| ) -> Result<n::ImageView, image::ViewCreationError> { |
There was a problem hiding this comment.
I would have preferred adding a Device::image_from_raw() method, but in my case it is OpenXR that creates the Vulkan images and it hides some details needed to construct gfx images.
zmerp
force-pushed
the
gfx-backend-vulkan-raw-handles
branch
from
5f8a1a6 to
6a0ff8b
Compare
1609: [Vulkan] Initialize wgpu objects from raw handles r=kvark a=zarik5 **Connections** This PR is a successor of gfx-rs/gfx#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 <[email protected]>
Related issues: #3698 #3761 blaind/xrbevy#1
This PR exposes some Vulkan-backend-specific details needed for interop with other low level APIs. In particular this PR aims to implement a minimum viable API to allow OpenXR integration as a separate crate.
This PR is nowhere complete. I opened it to get some feedback; this is my first PR on a project the size of gfx-hal.
This is the first of multiple PRs needed for OpenXR support in wgpu.
PR checklist:
makesucceeds (on *nix)make reftestssucceedsEDIT: To make things clear, this is another take on #3761. Me and @blaind are working together on this route.