search

doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
13.44k stars 868 forks source link

[d3d9] Device import API #4497

Open AlpyneDreams opened 3 days ago

AlpyneDreams commented 3 days ago

EDIT: See below. Instead of creating an async compute queue we instead allow the interop client to provide their own device

Currently, the DXVK interop app I'm working on needs to use the async compute queue. However, DXVK creates the device without any queues from the compute family. This PR simply adds an extra compute queue to the VkDeviceCreateInfo.

If there's some reason that we'd want to avoid doing this unless the interop client asks for it, for example if it might cause unexpected performance or behavior changes, then I can add another commit to this PR to make it conditional, but I wouldn't expect this to have any side effects at all since DXVK never uses async compute.

doitsujin commented 3 days ago

Not gonna lie, I don't like these interop PRs very much. This might not functionally change much, but it also makes zero sense for us to have this upstream since DXVK does not use or require a compute queue, all this does is create a maintenance burden for something that isn't even shipping.

We don't currently have a good API to import an existing Vulkan device (some functionality is there for importing a vkd3d-proton device, but there's no way to query required extensions / features etc right now), but I think that would be the way forward here.

AlpyneDreams commented 2 days ago

@doitsujin

Not gonna lie, I don't like these interop PRs very much. This might not functionally change much, but it also makes zero sense for us to have this upstream since DXVK does not use or require a compute queue, all this does is create a maintenance burden for something that isn't even shipping.

We don't currently have a good API to import an existing Vulkan device (some functionality is there for importing a vkd3d-proton device, but there's no way to query required extensions / features etc right now), but I think that would be the way forward here.

That's alright, I'm probably going to do most other changes I had planned on a fork from now on since they're too specialized for upstream (there's not many things left). I can still try to add a device import API. Something like the latest commit?

AlpyneDreams commented 2 days ago

The latest push has the implementation for a device import API. Here is an example of how it would be used. I have tested this with my project and I can confirm that it works.

Any thoughts or recommended changes on the implementation here? Nits welcome too @misyltoad @doitsujin