vkd3d: Enable vulkan extensions required for OpenVR.

[yshui]

This only loads the extension list from registry. I am still not sure why dxvk loads a different openvr dll, openvr_api_dxvk.dll, so I am not attempting getting that list from openvr directly.

Also I am not sure if this is the best way of getting this list to vkd3d_enable_extensions... please help?

[HansKristian-Work]

Is there a reason for us to query this from the registry? Can't we just enable the relevant extensions? Which extension does VR even need beyond what we enable in the first place?

[HansKristian-Work]

If you only need to enable extensions and not enable device level features as well, I think the proper place to do so is in d3d12/main.c where you can give optional extensions to instance/device creation. See where we enable surface_maint1 and swapchain_maint1. The code also needs to be ifdeffed behind WIN32.

[gofman]

Strictly speaking, we do not know in Proton what are the required extensions for VR, whether they are the same for every GPU or when they are going to be changed by Steam VR implementation. We query that from VR. So far we were avoiding hardcoding that and not sure if doing so would be a good idea.

[yshui]

@HansKristian-Work for instance extensions i think it's possible to move it to d3d12core/main.c, but for device extensions I need to know the physical device first

[HansKristian-Work]

we do not know in Proton what are the required extensions for VR

Most extensions require a Feature struct to be used though, and just enabling extensions is not enough. Has that not been a problem before?

[yshui]

Most extensions require a Feature struct to be used though

OpenVR doesn't have a mechanism for telling the application what feature struct to pass. In practice none of the extensions they use need a feature struct.

[HansKristian-Work]

I need to know the physical device first

I think you'll know that from the DXGI adapter in D3D12CreateDevice, right?

[Joshua-Ashton]

Why are we using the registry? Can't we just ask OpenVR itself?

[Joshua-Ashton]

https://github.com/doitsujin/dxvk/blob/master/src/dxvk/dxvk_openvr.cpp#L207

We do both in DXVK, but idk why? I don't see what the point of the vr key stuff is...

[yshui]

@Joshua-Ashton I assume there must be a reason for this :thinking: @gofman do you know?

[gofman]

Why are we using the registry? Can't we just ask OpenVR itself?

We were asking VR some years ago. That was breaking half of the VR games because Linux VR breaks after initializing and deinitializing in the same process, it never deinitializes cleanly and when app initializes it itself after us that was hanging or crashing. Doing that from a different process just once (from our steam.exe) worked better. Maybe there were some changes in this area since then but I doubt it was solved completely. Recently we lost one hack which was needed back then for Beat Saber which initializes VR twice (which hack was making sure vrclient.so after unititializing) and it got broken this way, getting that back helped. Back then it still didn't help on AMD, VR was still hanging after second initialization, but maybe that changed, there were some reports that it works on AMD now. That was even worth for openxr btw, that one was always hanging on xrDestroyInstance if any present was performed, that was reproducible on SDK sample. Didn't check that last year or two, but around so back that issue was still there.

Another point to this was device creation. Loading and creating VR / XR instances for every d3d device creation looked less than ideal performance wise, given many games create devices much more than once during initialization.

UPDATE: note that this VR initialization on each device creation had to happen for every game if VR is installed, not only for VR games.

[yshui]

@HansKristian-Work Thank you so much!