Transferring D3D textures to OpenGL or Vulkan contexts in Winelib

Ben "Root" Anderson roothorick at gmail.com
Tue May 16 14:24:01 CDT 2017


On Tue, May 16, 2017 at 9:40 AM, Józef Kucia <joseph.kucia at gmail.com> wrote:
> I'm just a bit skeptical about usefulness of this extension in Wine
> besides your use-case.

Definitely understandable. I think it's a big enough one to justify it
in and of itself, however; this is critical middleware for a rapidly
expanding library of games and applications. And I think getting
SteamVR itself running in Wine is unrealistic due to how
hardware-dependent it is.

> I'm not aware of such problems. Other WGL extensions are already
> implemented in Wine, see dlls/winex11.drv/opengl.c. In this case it
> may be a little harder though, the extension has to understand D3D9,
> D3D10 and D3D11 interfaces, and it has to talk to wined3d, and it has
> to presumably map GL objects to internal wined3d GL objects.

I was asking because I'm completely naive to how IP works with
OpenGL/WGL extensions. I take it, then, the vendor prefix has no
bearing on whether any kind of permission or license is needed for
implementation on the host side of things based solely on the public
specification? I must sound so green...

It's going to be some time, as I want to get a few Vulkan and/or
OpenGL programs to the point of submitting frames to the compositor
before I tackle the D3D nut, but if no one else looks in the meantime,
I'll have a go at implementing the dx_interop extensions and putting
together a pullreq myself. I mostly wanted to gauge the viability of
the project, as never having D3D11 support at all would defeat a large
part of the point.



More information about the wine-devel mailing list