72 lines
2.3 KiB
Plaintext
72 lines
2.3 KiB
Plaintext
include::meta/VK_NV_external_memory_capabilities.txt[]
|
|
|
|
*Last Modified Date*::
|
|
2016-08-19
|
|
*IP Status*::
|
|
No known IP claims.
|
|
*Interactions and External Dependencies*::
|
|
- Interacts with +Vulkan 1.1+.
|
|
- Interacts with `<<VK_KHR_dedicated_allocation>>`.
|
|
- Interacts with `<<VK_NV_dedicated_allocation>>`.
|
|
*Contributors*::
|
|
- James Jones, NVIDIA
|
|
|
|
Applications may wish to import memory from the Direct 3D API, or export
|
|
memory to other Vulkan instances.
|
|
This extension provides a set of capability queries that allow applications
|
|
determine what types of win32 memory handles an implementation supports for
|
|
a given set of use cases.
|
|
|
|
=== New Object Types
|
|
|
|
None.
|
|
|
|
=== New Enum Constants
|
|
|
|
None.
|
|
|
|
=== New Enums
|
|
|
|
* elink:VkExternalMemoryHandleTypeFlagBitsNV
|
|
* elink:VkExternalMemoryFeatureFlagBitsNV
|
|
|
|
=== New Structs
|
|
|
|
* slink:VkExternalImageFormatPropertiesNV
|
|
|
|
=== New Functions
|
|
|
|
* flink:vkGetPhysicalDeviceExternalImageFormatPropertiesNV
|
|
|
|
=== Issues
|
|
|
|
1) Why do so many external memory capabilities need to be queried on a
|
|
per-memory-handle-type basis?
|
|
|
|
*RESOLVED*: This is because some handle types are based on OS-native objects
|
|
that have far more limited capabilities than the very generic Vulkan memory
|
|
objects.
|
|
Not all memory handle types can name memory objects that support 3D images,
|
|
for example.
|
|
Some handle types cannot even support the deferred image and memory binding
|
|
behavior of Vulkan and require specifying the image when allocating or
|
|
importing the memory object.
|
|
|
|
2) Does the slink:VkExternalImageFormatPropertiesNV struct need to include a
|
|
list of memory type bits that support the given handle type?
|
|
|
|
*RESOLVED*: No.
|
|
The memory types that do not support the handle types will simply be
|
|
filtered out of the results returned by flink:vkGetImageMemoryRequirements
|
|
when a set of handle types was specified at image creation time.
|
|
|
|
3) Should the non-opaque handle types be moved to their own extension?
|
|
|
|
*RESOLVED*: Perhaps.
|
|
However, defining the handle type bits does very little and does not require
|
|
any platform-specific types on its own, and it is easier to maintain the
|
|
bitmask values in a single extension for now.
|
|
Presumably more handle types could be added by separate extensions though,
|
|
and it would be midly weird to have some platform-specific ones defined in
|
|
the core spec and some in extensions
|