Texture from ID3D12Resource/ID3D11Resource?

[mycrl]

I've tried searching the issues have looked at crate's documentation and there doesn't seem to be a way to directly use resources from other D3D devices right now, such as 2d texture, is that because of something that's causing a blockage or is there a plan in place but no support right now?

I'd probably want an interface like Texture::from_raw_texture or something like that, where the user handles the use of different raw textures under different backends themselves.

There doesn't seem to be any way to do this or an alternative at the moment, except for a custom wgpu backend, I guess.

This is useful in scenarios where high performance hardware acceleration is required, for example, the frame output from a hardware video decoder is ID3D11Resource2DTexture, which the wgpu would need to transfer to memory via the cpu and then submit to the wgpu's memory by copying the texture from the software, which is an expensive way to do it! .

I'm just illustrating the use of D3D devices here, other backends should be able to provide support in the same way.

[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.

[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

[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.