Definition (or not) of IDXGIResource methods

[Ben "Root" Anderson]

On Mon, Jul 3, 2017 at 1:52 PM, Henri Verbeet <hverbeet at 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.