Direct3D support not yet implemented

[roothorick]

Obviously, the Linux SteamVR runtime doesn't implement anything Direct3D related. That means we need to, somehow, take the submitted ID3D11Texture2D objects and convert them into a Vulkan or GL texture.

This is more complicated than it sounds, and it already sounds pretty complicated.

First, OpenGL is for all intents and purposes off limits. OpenGL contexts are process-bound; that is, only one context can be active per process. To use OpenGL at all, we have to make assumptions about how Wine is using (or not using) OpenGL. This is a hairy prospect, and likely to break frequently and without notice.

That leaves Vulkan, which has no such limitations. Any given thread may have an arbitrary number of Vulkan instances without any cooperation or even knowledge of each other. That means, if we implement D3D support as a wrapper around Vulkan, then if a theoretical "VK11" comes along, so long as it implements the appropriate context and resource sharing functionality, it'll work without any modifications to WineOpenVR.

So far, so good. But that leaves the problem of extracting the eye textures from the ID3D11Texture2D submitted by the application. For encapsulation reasons, we can't access the GL texture underneath.

The Nvidia developer blog has some sample code here, of how to share a D3D11 texture with a Vulkan instance: https://developer.nvidia.com/getting-vulkan-ready-vr This should make for a good reference of what functionality needs to be implemented in Wine. To avoid copying textures to the CPU, some very new GL extensions will need to be leveraged (GL_EXT_memory_object and friends). The pullreq for those extensions is here: https://github.com/KhronosGroup/OpenGL-Registry/pull/65

We'll need to modify wine-staging's Vulkan implementation as well, to implement the relevant win32-specific extensions.

One last complication. The sharing flags mentioned on Nv's blog above are not set by any of the applications I've checked (in all cases, MiscFlags == 0). So once everything's implemented in all the necessary places, we'll still need to reach into the application's device context, make a copy of the eye texture with the shared flags set, then import that.

This is not gonna be easy.

[CrossVR]

I think you should just use the encapsulated GL texture, perhaps through a fork on wine. That also makes it possible to submit OpenVR-support as a patch to wine at some point.

[roothorick]

The Wine general policy is that as a third-party, non-MS app, SteamVR should itself be made to run under Wine. I don't consider that feasible, thus WineOpenVR.

That means a patch to "jailbreak" the GL texture wouldn't be accepted, so I'd have to maintain it myself against a very fluid section of the Wine codebase. That's a maintenance nightmare and leaves a big nasty hairball in end users' laps with needing custom unsupported bits of Wine.

[CrossVR]

I wouldn't really call OpenVR an MS app, but I do see your point. Perhaps once OpenXR is ratified wine could support translating OpenXR calls to native SteamVR.

[mirh]

'VK11' seems starting to be a thing. It's a long shot from usable though, and tbh I'm always saddened by linux ending up getting hardware/features disparities from windows.

[roothorick]

My current plan, in theory, is to use dxvk's official interop API. I haven't had time to really investigate how it works myself (and learn what it all does from a Vulkan standpoint), but I'm making a note here in case anyone else is feeling ambitious.

[CrossVR]

I'm still betting on native OpenXR support in wine once it's ratified. In which case if it would make more sense to translate OpenVR to OpenXR if that's needed.

[roothorick]

This isn't a SteamVR problem so much as just how VR necessarily interacts with a translation/emulation layer like Wine. Ultimately, for a GPU-side resource to jump between APIs without leaving the GPU, said APIs need to cooperate in an explicit way, so that one can generate its own handles for resources originally created by the other. (Ideally, but not necessarily, vice versa.) For a Linux-native VR runtime of any type or description to work with Direct3D applications in Wine at all, either Wine or something running inside it needs to be able to translate an ID3D11Texture2D into an OpenGL texture handle or a VkImage.

That means, from a graphics API perspective, Wine implementing OpenXR will most likely only change who's solving the problem, not the problem itself. That said, if the Wine developers figure out this mess themselves, I'm all for it!

[CrossVR]

That means, from a graphics API perspective, Wine implementing OpenXR will most likely only change who's solving the problem, not the problem itself.

If Wine implements OpenXR they would have access to the underlying OpenGL texture. OpenXR is being developed by the same standards body that maintains OpenGL. It would make sense if Wine supported that API directly just like they support OpenGL.