wgpu
wgpu copied to clipboard
gfx-rs
Vulkan: create texture from d3d11 shared handle
Description VK_KHR_external_memory_win32 extension enables application to import Vulkan memory objects from Windows handles.
Testing
- Create D3D11 texture with D3D11_RESOURCE_MISC_SHARED_NTHANDLE and D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX flags
- Create shared handle with IDXGIResource1::CreateSharedHandle
- Create vulkan texture with
texture_from_d3d11_shared_handle
Checklist
- [x] Run
cargo fmt. - [x] Run
cargo clippy. If applicable, add:- [ ]
--target wasm32-unknown-unknown - [ ]
--target wasm32-unknown-emscripten
- [ ]
- [x] Run
cargo xtask testto run tests. - [ ] Add change to
CHANGELOG.md. See simple instructions inside file.
@cwfitzgerald Does this PR need any other improvements? This feature is already working properly in our product.
Hello. I've been working on sharing textures with wgpu using both Dx12 and Vulkan but without doing any changes to wgpu itself. My memory allocation code ended up looking very similar with important difference: vk::ExternalMemoryHandleTypeFlags::D3D12_RESOURCE instead of vk::ExternalMemoryHandleTypeFlags::D3D11_TEXTURE. Other types could potentially be also usable for storing textures. If possible I would encourage to add it as a parameter next to d3d11_shared_handle.
In fact this new method is called texture_from_d3d11_shared_handle which makes my comment a little misplaced. Still, adding this parameter would make this code more usable.
Change to adapter to add external_memory_win32 capabilities is very nice - otherwise one has to extract raw adapter from wgpu, copy code from here, add required enabled_extensions to the list and then inject it back with adapter .create_device_from_hal which is a pain.
Other considerations: If I'm not wrong, NT handle holds the resource alive and it won't be cleaned up unless you call CloseHandle. I may be wrong here but I think Vulkan will NOT close the handle itself so user should do that manually. In my specific situation (sending textures between processes) I'm managing handles outside of wgpu - I remove injected shared textures from wgpu and it gets sent to different process. I think that this ownership situation should be reflected in documentation of this method (but please don't quote me on that, I'm not 100% sure how exactly this mechanism works after reading documentation and my limited tests).
I too have the interop code here if that's helpful to anyone. One thing I had to do is copy the texture format (DXGI_FORMAT) conversion functions, it would be nice if they were exposed from wgpu
@Tsuguri VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_BIT owns a reference to the memory used by the Direct3D resource, after importing the handle can be released safely.