Ideally applications should not be dxvk aware... Is there a practical use case for you here?
There is always the manifest info which mentions dxvk though
The practical use case for this is working around a possible issue with recent D3D9 AMD drivers:
https://github.com/Cxbx-Reloaded/Cxbx-Reloaded/blob/6a70a08c592af8d4259104a50a750ff95068e72b/src/core/hle/D3D8/Direct3D9/Direct3D9.cpp#L1636
DXVK renders this hack useless, so it could just be skipped.
That said, you're right - obtaining manifest data via VerQueryValue from a d3d9.dll loaded in the process might do the trick too!
There is a DXVK interop interface now so... Closing.
d3d9.dllx1 2020-10
For DXGI implementations, DXVK currently provides interop interfaces which can be used by applications in order to "detect" DXVK. With D3D9, there seems to be nothing - it is impossible to query for an interface which unambiguously differentiates real D3D9 from the one provided by DXVK.
All that's needed from DXVK is an extra interface implemented by
D3D9InterfaceExwhich can be queried for - could even be empty, given it would not be used to interoperate but just to "detect" DXVK. A failure to obtain it fromIDirect3D9::QueryInterfacewould indicate DXVK is not used.This will come in handy for D3D9 applications which intend to be DXVK aware - which is especially important lately with all the D3D9 regressions with recent AMD drivers.