There are already interfaces for this purpose, which are used in Proton's OpenVR bridge:
https://github.com/doitsujin/dxvk/blob/ae01bd8bd40cd8dbcc35dfedbabe9624d31fa72e/src/dxgi/dxgi_interfaces.h#L154
These are less generic and currently there's no way to interact with Vulkan buffers, but if you have a use case I'll consider adding that. To detect DXVK, there are probably about a dozen different interfaces specific to DXVK that could be queried by an application.
What exactly is your use case anyway?
Oh nice, I have not checked DXGI and only checked D3D9. Good to know!
I don't have a specific use case as of now, but I imagine it could be useful for projects like ReShade, which could use this to leverage features not available from D3D9/D3D10/D3D11 by default.
I have something that does let you do a little interop in a patch you can apply here: https://github.com/Joshua-Ashton/d9vk/commit/e249399ccff4a397ce8ee9565954554ac55fa1d0
As for something more verbose and in master, I do not, no.
I have something that does let you do a little interop in a patch you can apply here: Joshua-Ashton/d9vk@e249399
As for something more verbose and in
master, I do not, no.
Will check! As for use cases, a more relevant use case would be to allow software (most notably emulators) for easier migration to Vulkan. Two examples are Cxbx-R (xbox emulator, currently using DX9) and PCSX2 (PS2 emulator, currently offering DX11) - with such downlevel interfaces they could technically implement native Vulkan step by step, with the application working at all times.
I would really not reccomend porting like this.
and PCSX2 (PS2 emulator, currently offering DX11)
PCSX2 also has an OpenGL renderer which is what the developers recommend you to use on Windows too.
I would really not reccomend porting like this.
Porting without being able to test intermediate steps is a massive task however.
PCSX2 also has an OpenGL renderer which is what the developers recommend you to use on Windows too.
That's not the point, the point is they are contemplating adding Vulkan eventually and a downlevel interface like this could potentially help.
Porting without being able to test intermediate steps is a massive task however.
That's why you try/test things as you go. Seeing those successes will also motivate you to continue with the project.
Using DXVK + some interop to port is not going to end well or result in anything clean.
Nothing extracted yet.
This is a feature suggestion with fairly low priority, but I imagine it could be useful in some isolated cases, especially revolving around modding.
As it stands there seems to be no way for the application to determine whether it's running with "real" D3D or with DXVK, since there is no way to query for it via
QueryInterface. Both D3D9On12 and D3D11On12 implement such interfaces, so applications can do things like:As of now, it doesn't seem to be possible with DXVK - do you think it's worth expanding wrapped devices with a new interface like this?