Applications may wish to export memory to other Vulkan instances or
other APIs, or import memory from other Vulkan instances or other APIs
to enable Vulkan workloads to be split up across application module,
process, or API boundaries. This extension enables applications to
create exportable Vulkan memory objects such that the underlying
resources can be referenced outside the Vulkan instance that created
them.
1) If memory objects are shared between processes and APIs, is this
considered aliasing according to the rules outlined in the
Memory Aliasing
section?
RESOLVED: Yes, but strict exceptions to the rules are added to allow
some forms of aliasing in these cases. Further, other extensions may
build upon these new aliasing rules to define specific support usage
within Vulkan for imported native memory objects, or memory objects from
other APIs.
2) Are new image layouts or metadata required to specify image layouts
and layout transitions compatible with non-Vulkan APIs, or with other
instances of the same Vulkan driver?
RESOLVED: No. Separate instances of the same Vulkan driver running
on the same GPU should have identical internal layout semantics, so
applications have the tools they need to ensure views of images are
consistent between the two instances. Other APIs will fall into two
categories: Those that are Vulkan compatible (a term to be defined by
subsequent interopability extensions), or Vulkan incompatible. When
sharing images with Vulkan incompatible APIs, the Vulkan image must be
transitioned to the
IMAGE_LAYOUT_GENERAL layout before
handing it off to the external API.
Note this does not attempt to address cross-device transitions, nor
transitions to engines on the same device which are not visible within
the Vulkan API. Both of these are beyond the scope of this extension.
EXTERNAL_MEMORY_HANDLE_TYPE_D3D11_IMAGE_BIT_NV specifies a valid
NT handle to memory returned by
IDXGIResource1::CreateSharedHandle, or a handle duplicated from
such a handle using DuplicateHandle().