I'd like to start a discussion here and see where it goes.
First, my usecase. I want to write a wrapper that connects Windows SteamVR applications running under Wine to the native Linux SteamVR runtime. Because it's the same API on both sides, this is very straightforward, except for one crucial element. In their API, the application does not (necessarily) output the rendered frame to a window, instead submitting the frame to their VR compositor as either an ID3D11Texture, a struct describing a D3D12 texture, an OpenGL texture or render buffer name, or a struct describing a Vulkan texture. For obvious reasons, the latter two are the options available on Linux, making them very straightforward for a Winelib DLL. The former two... not so much.
The vast majority of SteamVR applications are currently using Direct3D 11, which means for any of this to work with them, I need some way to convert an ID3D11Texture to the appropriate OpenGL or (preferably) Vulkan equivalent that SteamVR is expecting. I've looked high and low and see no way to do this, neither through Windows APIs nor Winelib. Just to get things working for now, I'll likely figure out a way to invoke wined3d_texture_get_gl_buffer() or similar from outside Wine itself, but that's a dirty hack at best and likely to break frequently (eventually, maybe permanently) as Wine evolves.
Thoughts?
On Sun, May 14, 2017 at 4:11 AM, Ben "Root" Anderson roothorick@gmail.com wrote:
I'd like to start a discussion here and see where it goes.
First, my usecase. I want to write a wrapper that connects Windows SteamVR applications running under Wine to the native Linux SteamVR runtime. Because it's the same API on both sides, this is very straightforward, except for one crucial element. In their API, the application does not (necessarily) output the rendered frame to a window, instead submitting the frame to their VR compositor as either an ID3D11Texture, a struct describing a D3D12 texture, an OpenGL texture or render buffer name, or a struct describing a Vulkan texture. For obvious reasons, the latter two are the options available on Linux, making them very straightforward for a Winelib DLL. The former two... not so much.
The vast majority of SteamVR applications are currently using Direct3D 11, which means for any of this to work with them, I need some way to convert an ID3D11Texture to the appropriate OpenGL or (preferably) Vulkan equivalent that SteamVR is expecting. I've looked high and low and see no way to do this, neither through Windows APIs nor Winelib. Just to get things working for now, I'll likely figure out a way to invoke wined3d_texture_get_gl_buffer() or similar from outside Wine itself, but that's a dirty hack at best and likely to break frequently (eventually, maybe permanently) as Wine evolves.
In theory Wine could implement WGL_NV_DX_interop [1] and WGL_NV_DX_interop2 [2].
[1] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt [2] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop2.txt
Been a while since I've done mailing lists. I forgot to reply-all.
On Sun, May 14, 2017 at 2:53 AM, Józef Kucia joseph.kucia@gmail.com wrote:
In theory Wine could implement WGL_NV_DX_interop [1] and WGL_NV_DX_interop2 [2].
[1] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop.txt [2] - https://www.khronos.org/registry/OpenGL/extensions/NV/WGL_NV_DX_interop2.txt
In theory?
The main question I can't find the answer to is, are there any potential copyright/IP problems (or just Wine policy issues) with implementing these extensions "paint by numbers" off the published specs?
-
Ben "Root" Anderson -
Józef Kucia