Is there a way to somehow get Vulkan resources out of d3d9.dll? SteamVR supports Vulkan directly, if I could get Vulkan back buffer image, I won't need the above queue mechanism. Would this be possible somehow? I think I am going to try fork and add additional export just for this, but wonder if anyone has better suggestions? Thanks.

There is nothing exposed but I did this a while back for Source Engine VR myself. https://github.com/Joshua-Ashton/d9vk/tree/virtual-reality

Should be pretty easy to rebase

@Joshua-Ashton - do you know if it is at all possible to build dxvk on Windows, or it actually requires Linux environment? I made some progress today, but I suspect I am heading nowhere:

2/45] Compiling C++ object src/util/libutil.a.p/log_log.cpp.obj
FAILED: src/util/libutil.a.p/log_log.cpp.obj
"i686-w64-mingw32-g++" "-Isrc\util\libutil.a.p" "-Isrc\util" "-I..\src\util" "-I..\include" "-fdiagnostics-color=always" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-Wnon-virtual-dtor" "-std=c++17" "-O3" "-DNOMINMAX" "-D_WIN32_WINNT=0xa00" "-msse" "-msse2" "-msse3" "-mfpmath=sse" -MD -MQ src/util/libutil.a.p/log_log.cpp.obj -MF "src\util\libutil.a.p\log_log.cpp.obj.d" -o src/util/libutil.a.p/log_log.cpp.obj "-c" ../src/util/log/log.cpp
../src/util/log/log.cpp: In constructor 'dxvk::Logger::Logger(const string&)':
../src/util/log/log.cpp:13:69: error: no matching function for call to 'std::basic_ofstream::basic_ofstream(const wchar_t*)'
m_fileStream = std::ofstream(str::tows(path.c_str()).c_str());
^
In file included from ../src/util/log/log.h:4,
from ../src/util/log/log.cpp:1:
d:/Repos/deps/mingw-win32-i686-8.1.0-posix-dwarf/mingw32/lib/gcc/i686-w64-mingw32/8.1.0/include/c++/fstream:780:7: note: candidate: 'std::basic_ofstream<_CharT, _Traits>::basic_ofstream(std::basic_ofstream<_CharT, _Traits>&&) [with _CharT = char; _Traits = std::char_traits]'
basic_ofstream(basic_ofstream&& __rhs)
^~~~~~~~~~~~~~

And thanks for sharing your branch, I'll keep pushing.

meson --backend vs2019 --buildtype release build in a Visual Studio command prompt.

Yess, I got it to build in Release, but I had to define:

#define VK_USE_64_BIT_PTR_DEFINES 1

otherwise:

6>D:\repos\dxvk\src\dxvk\dxvk_framebuffer.h(68,1): error C2440: 'reinterpret_cast': cannot convert from 'const VkRenderPass' to 'uint64_t'

Any idea what is going on?
In any case big thanks, I was close to hanging myself with all the distros of mingw-w64.

Edit: looks like I celebrated too early - resulting binary hits stack corruption and is much smaller than official d3d9.dll by rolling build, not sure if it is related to the above issue. I think I am going to try Ubuntu next.

Solved it: it was about threading mismatch wiki/compliation issues.

I installed Ubuntu 20.04 VM and with mingw-w64 v 7.0.0.2 (updated to 8.0.0.0 did not help) I get errors:

cv_status does not name a type in namespace std
also std::this_thread not defined.

Feels like I am missing some configuration step, any suggestions?

After I fixed compliation errors I still get:

allocatelocallyuniqueid entry point missing from d3d9.dll
d3d9.dll is slightly smaller than what is coming out of release builds here ~2.9Mb vs ~3.1mb.

Any suggestions?

Edit: ok, figured it out. Created a docker based on this file, now I have successful build and binaries work: https://github.com/Joshua-Ashton/arch-mingw-github-action/blob/master/Dockerfile

@Joshua-Ashton I managed to connect all the pieces, but game hangs on very first IDirect3DVR9::Presubmit call. Do I understand correctly, that those were intended to be called:

IDirect3DVR9::Presumbit
IDirect3DVR9::GetVRDesc
vr::VRCompositor()->Submit
IDirect3DVR9::Postsumbit
?

Do you remember if you had to initialize OpenVR somehow in a special way for DXVK to work? Thanks in advance.

Feels like I am missing some configuration step, any suggestions?

We don't support ancient MinGW or MinGW without pthreads. Use Arch or something.

And ye, that seems to be the order to be called. Something may have changed or been broken, it has been years.

Feels like I am missing some configuration step, any suggestions?

We don't support ancient MinGW or MinGW without pthreads. Use Arch or something.

And ye, that seems to be the order to be called. Something may have changed or been broken, it has been years.

Thanks - I figured out the build, your activity from CI was super helpful. I am now building DXVK in ArchLinux Docker container 👍

I suspect OpenVR initialization for Vulkan is very different from what it is for DX11, so it is not enough to just get GetVRDesc and send it to Submit, I think I will have rewrite all OpenVR code I have - or am I overthinking here?

EDIT: made a bit of progress - Presubmit hangs on very first LockDevice call.

Well I made significant progress by using Joshi's class to get to the Vulkan images from behind DX9 and they do show up in VR. However, I am experiencing constant hangs and races, it seems like I am missing some synchronization somewhere. Sharing stacks here, maybe someone will have any insights. Thanks in advance!
stacks.txt

I got to a point where my code runs fine in VR via DXVK. The only problem is it runs 1 out of 20 times I start the process. Most of the time I get:

vkAllocateMemory failed with result -2

Coming from OpenVR SetOverlayTexture or Submit. That one time it starts correctly, however everything runs nicely, so it is some sort of race at OVR initialization time, any ideas how to fix this?

So the last issue turned out to be SteamVR issue. I opted into beta version and vkAllocateMemory error is gone.

I am closing this issue as shared surfaces are not needed for SteamVR - submitting Vulkan images works, although there are things that would be nice DXVK to support, such as precise frame timing for OpenVR.

@Joshua-Ashton thank you very much for sharing your branch it got me started and I am making steady progress now.