On Mon, Jul 3, 2017 at 1:52 PM, Henri Verbeet hverbeet@gmail.com wrote:
I expect ultimately you'll need some way to get at the underlying OpenGL object. One way to go about that may to for example extend the IWineDXGIDevice interface in include/wine/winedxgi.idl with a method to retrieve the underlying OpenGL object of a resource.
Thanks for the tip. It'll likely make a good temporary hack until I put together the (sizable) proper solution. The added functions may even wind up being a part of said solution.
There are some details to take care of there though. For one, while wined3d is implemented on top OpenGL, that's an implementation detail and may not be true forever. A D3D surface/texture could be backed by an OpenGL texture, an OpenGL renderbuffer, both, or something else entirely, so you'll probably want some kind of interface to negotiate the kind of representation you're requesting. Even if for simplicity we assume we have a D3D texture backed by an OpenGL texture, that doesn't guarantee that at any given time that OpenGL texture is current/coherent. (See also, wined3d_texture_load_location(), wined3d_texture_validate_location(), wined3d_texture_invalidate_location(), etc.) So you may need a way to flush/synchronise that OpenGL texture as well. And while IWineDXGIDevice may be a good way to prove the concept, that's an internal interface that doesn't make any guarantees about interface stability, so for something that you'd want to use to interface with external software, it would be best to create a separate interface that does make those kinds of guarantees.
Yeah, I definitely want to avoid interfaces that aren't agnostic to the underlying implementation, at which point it makes more sense to instead implement the relevant Windows APIs.
My current plan is to make and submit a patch to wine-staging that implements VK_KHX_external_memory_win32 and the Direct3D/DXGI functionality needed to interact with that extension from Direct3D; this implementation would very probably lean on GL_EXT_memory_object and related extensions. Then, I'd use those interfaces to import the textures into a Vulkan instance, which is then passed to the compositor.
Finally, does this need to work with arbitrary resources, or do you only need this for e.g. swapchain buffers?
It needs to work not with swapchain buffers, but a pair of ID3D11Texture2D objects that are created by the application for the express purpose of being passed to the API I'm wrapping. One or both of these textures may or may not also be presented by the application in its own window through the usual D3D process, but I do not know and am not supposed to know whether they are, and shouldn't care. (Some apps actually render and present a completely separate scene in their window.)
I need to ultimately pass the textures to the native Linux version of the compositor in a form it can digest (specifically, either a GL texture or render buffer name, or a VkImage and associated instance structs), which then (among other things) presents it in the HMD using its own (Vulkan) swapchains.