RFC: VK_EXTERNAL_MEMORY_WIN32 extension patch

[Derek Lesho]

Hello, before I break this patch up and submit a patchset, I'd like to
inquire about a few things in this patch I have made.

The biggest question I have is how we want to process allocate_info without
modifying what is passed in.

In order to copy the whole pNext chain or the unknown bits, we'd need a way
to get the struct length given the sType.  To do this we'd have to generate
something in make_vulkan, but I'm not sure of the specifics (mostly where
the helper would go).

Alternatively, we could try restoring the chain after it is finished,
however this may not be thread safe, if the struct is being read in another
thread.

Additionally, I'd like to know how to better organize the functions for
creating/operating on gpu-resource objects.  Right now they're in ntdll's
misc.c, so that I can use some ntdll internal functions, but maybe we
should have a separate file for this.

If any of you want to play around with this patch, Joshua Ashton (d9vk
creator) made a few patches on DXVK that implement D3D shared resources
using this extension and files, and  modified a D3D example to use shared
resources, which is what I've been using to test my implementation:

https://github.com/Joshua-Ashton/dxvk/tree/dxvk-shared-resources

D3D11 binary attached (Joshua didn't send me source)

Note: Make sure to reset to HEAD~1 then build, as I think the latest commit
is broken.  Also, replace
VK_EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_TEXTURE_(+KMT_)BIT with
VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_WIN32_(+KMT_)BIT.  Also, this branch
only compiles with MSVC.  Alternatively, I'll attach the binaries to this
email.

Note 2: Make sure to use native d3dcompiler_47

 Shared-Resources.tar.xz
<https://drive.google.com/file/d/112N8xhnUJ0FyBDodgbP42fD31-VLq5ka/view?usp=drive_web>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190728/dd73ff09/attachment.html>