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: KhronosGroup/OpenGL-Registry#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.