[wgpu-hal][Vulkan] Possibly changing the difference in behavior of `drop_guard` between `Instance::from_raw` and `Device::texture_from_raw`
jerzywilczek opened this issue · comments
When talking about Instance, Adapter and Device i mean wgpu_hal::vulkan::{Instance, Adapter, Device}
Currently, both Instance::from_raw and Device::texture_from_raw accept a drop_guard as a parameter. The behavior of the drop guard is completely different though.
When a texture is created with a drop guard, wgpu_hal will not destroy the underlying vulkan image when dropping the texture. It will destroy the drop guard though, thus signalling that wgpu is not using the resource anymore. This is what I expected would happen in both cases.
When an instance is created with a drop guard, the behavior is reversed: if the drop guard is present, wgpu will destory the drop guard and the underlying vulkan instance, and when the drop guard is absent the instance will not be destroyed. This is not intuitive to me at all, it's hard for me to find a use case for that behavior.
Additionally, the function Adapter::device_from_raw does not take a drop guard, but accepts a handle_is_owned bool, which controlls whether wgpu will destroy the underlying vulkan device when dropping the created Device.
Ideally, I would like all three of these functions to share the same behavior: the one the Device::texture_from_raw has. I'm working on a project which needs to initialize vulkan by itself and I would like to provide my API clients access to a wgpu device created with the same underlying vulkan device. The API inconsistency makes this difficult.
I looked at the PR that introduced these behaviors: #1850. It seems these are tailored to one specific use case mentioned in the PR description.
Is it possible for this to be changed? I'm happy to work on this myself if the change is possible.
What a mess! Yes, lets definitely unify it. I think instead of a drop guard, we should just make the function a standard callback function. If we internally need that callback to be called in a drop guard, we can have that internally, but that shouldn't infect the api.