search

doitsujin / dxvk

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

[d3d9] Add ID3D9InteropBuffer for vertex buffers, index buffers, surfaces, and volumes #4411

Closed AlpyneDreams closed 3 weeks ago

AlpyneDreams commented 3 weeks ago

Exposes everything that has a DxvkBuffer to have its underlying VkBuffer(s) accessed the same way that VkImages can already be accessed for textures. Also extends ID3D9InteropTexture to be returned by volumes in addition to textures and surfaces. Interfacing with vertex buffers, index buffers, and volumes are essential features for interop.

K0bin commented 3 weeks ago

Is there anyone asking for this functionality?

AlpyneDreams commented 3 weeks ago

Is there anyone asking for this functionality?

This is extremely sketchy and honestly looks like a bad idea. Why is this needed anyway?

The project I am working would benefit immensely from being able to bind (or access bindlessly) vertex and index buffers for compute shaders or to use them to build raytracing acceleration structures etc. Most of this is work that would be done while DXVK is locked and no commands are issued.

FWIW I think image interop is technically broken as well right now due to defrag, but that's far less problematic to fix.

I have been using it pretty extensively just fine for a couple months now, however I think there are sometimes issues after the device resets or changes mode so you're probably right there.

If some sort of data exchange with client apps is actually required, I'd much rather do that as a self-contained API that lets you copy data between a D3D9 buffer and app-managed Vulkan buffers, but as it stands, this is not safe and effectively locks in our locking and memory management implementations, which is not really acceptable.

That's a very fair point. Since there's so many issues with this PR, I'll go back to the drawing board and see if there's a more narrow set of functionality we can expose. Ideally I think it would be preferrable to avoid duplicating all buffers just for the interop client, so I'll see if I can think of an API that's adaptable to any kind of implementation details while still exposing access to the device-side VkBuffers for just geometry under narrow circumstances.