`Texture` from `ID3D12Resource/ID3D11Resource`?

[mycrl]

`Texture` from `ID3D12Resource/ID3D11Resource`?

[AdrianEddy]

First of all, you mentioned that it is possible to interoperate outside of wgpu, how is this possible? Currently, there doesn't seem to be any method or implementation for the Texture type that returns the internal raw texture.

There are texture_from_raw , create_texture_from_hal, as_hal and raw_device methods already in wgpu which allow all the access to raw resources and importing/exporting them to/from external code. Check out the code I linked, it uses all these methods and it works fine

[AdrianEddy]

there's #6161 but in general there's no universal interface to interop with all possible APIs.
I also wish there were, but for now I have a few interops implemented in Gyroflow in wgpu_interop*.rs ( gyroflow/gyroflow#565 )

btw, as far as I can tell, all the interops are possible to implement outside of wgpu, so wgpu itself doesn't need to change any APIs. It would be really nice to have it directly there though. If not, I was thinking about implementing it in a separate crate (and name it like wgpu-interop)

That might be a good question to the maintainers: Do you prefer more PRs like #6161 or a separate crate for these zero-copy texture/buffer interops?

[mycrl]

@AdrianEddy Thank you for answering my questions!

First of all, you mentioned that it is possible to interoperate outside of wgpu, how is this possible? Currently, there doesn't seem to be any method or implementation for the Texture type that returns the internal raw texture.

My understanding is that wgpu's Texture is just a wrapper around the backend texture, and if I'm wrong then there really isn't a good way to implement the as_raw and from_raw I mentioned above.

At the moment I don't need to interoperate between different backends, I think #6161 is for interoperating between different backends, from D3D to Vulkan.

Maybe I'm not describing it very well, what I might need is that if the backend wgpu is currently using is D3D, then Texture::from_raw_texture can only use D3D resources, and the same goes for other backends.

What I mean is, when wgpu and other external implementations are using the same backend, how can we easily use the external resources with zero overhead instead of sharing the resources between different implementations.

Because in reality, other implementations or modules (not even Rust at all) often use the same GPU devices and graphics APIs as the wgpu, in which case the resources of the other implementation or module can actually be used directly by the wgpu at zero or low cost.

Finally, to answer your last question, if the wgpu is using the same set of graphics APIs as the external implementation and needs to interoperate at this point, then I'd be inclined to have the wgpu itself support this behavior, but if it's across different graphics APIs/backends then I think it's best to let the external crate do the work and the wgpu doesn't have much need to bother with it.

Of course, this is just my personal opinion, so please forgive me and bring it up if you find it problematic.

[mycrl]

Sorry, I saw the method from_hal before but didn't understand how to use it, it feels like the example you gave here(https://github.com/gyroflow/gyroflow/blob/master/src/core/gpu/wgpu_interop_directx.rs#L186)
Sorry for taking up your time and thanks again.