New subject: Definition (or not) of IDXGIResource methods

3 Jul 2017


      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.

Re: Definition (or not) of IDXGIResource methods