-
Notifications
You must be signed in to change notification settings - Fork 933
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[d3d9] Async compute queue #4497
Conversation
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? |
c4bf3d0
to
c96b54e
Compare
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 |
Going to move this to a new PR when I'm done with some improvements to the API. |
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 theVkDeviceCreateInfo
.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.