Jesse Hall critsec
- Last Modified Date
- IP Status
No known IP claims.
Ray Smith, ARM
Chad Versace, Google
Jesse Hall, Google
Tobias Hector, Imagination
James Jones, NVIDIA
Tony Zlatinski, NVIDIA
Matthew Netsch, Qualcomm
Andrew Garrard, Samsung
This extension enables an application to import Android
AHardwareBuffer objects created outside of the Vulkan device into
Vulkan memory objects, where they can be bound to images and buffers.
It also allows exporting an
AHardwareBuffer from a Vulkan memory
object for symmetry with other operating systems.
But since not all
AHardwareBuffer usages and formats have Vulkan
equivalents, exporting from Vulkan provides strictly less functionality than
AHardwareBuffer externally and importing it.
AHardwareBuffer images have implementation-defined external
formats that may not correspond to Vulkan formats.
Sampler Y′CBCR conversion can be used to sample from these images and
convert them to a known color space.
1) Other external memory objects are represented as weakly-typed handles
HANDLE or POSIX file descriptor), and require a handle type
parameter along with handles.
AHardwareBuffer is strongly typed, so naming the handle type is
Does symmetry justify adding handle type parameters/fields anyway?
The handle type is already provided in places that treat external memory
In the places we would add it, the application code that would have to
provide the handle type value is already dealing with
AHardwareBuffer-specific commands/structures; the extra symmetry
would not be enough to make that code generic.
2) The internal layout and therefore size of a
image may depend on native usage flags that do not have corresponding Vulkan
Do we provide this information to vkCreateImage somehow, or allow the
allocation size reported by vkGetImageMemoryRequirements to be
RESOLVED: Allow the allocation size to be unspecified when allocating the
It has to work this way for exported image memory anyway, since
AHardwareBuffer allocation happens in vkAllocateMemory, and
internally is performed by a separate HAL, not the Vulkan implementation
There is a similar issue with vkGetImageSubresourceLayout: the layout
is determined by the allocator HAL, so it is not known until the image is
bound to memory.
3) Should the result of sampling an external-format image with the suggested
Y′CBCR conversion parameters yield the same results as using a
samplerExternalOES in OpenGL ES?
RESOLVED: This would be desirable, so that apps converting from OpenGL ES to Vulkan could get the same output given the same input. But since sampling and conversion from Y′CBCR images is so loosely defined in OpenGL ES, multiple implementations do it in a way that does not conform to Vulkan’s requirements. Modifying the OpenGL ES implementation would be difficult, and would change the output of existing unmodified applications. Changing the output only for applications that are being modified gives developers the chance to notice and mitigate any problems. Implementations are encouraged to minimize differences as much as possible without causing compatibility problems for existing OpenGL ES applications or violating Vulkan requirements.
4) Should an
usage be mappable in Vulkan? Should it be possible to export an
AHardwareBuffers with such usage?
RESOLVED: Optional, and mapping in Vulkan is not the same as
The semantics of these are different: mapping in memory is persistent, just
gives a raw view of the memory contents, and does not involve ownership.
AHardwareBuffer_lock gives the host exclusive access to the buffer, is
temporary, and allows for reformatting copy-in/copy-out.
Implementations are not required to support host-visible memory types for
imported Android hardware buffers or resources backed by them.
If a host-visible memory type is supported and used, the memory can be
mapped in Vulkan, but doing so follows Vulkan semantics: it is just a raw
view of the data and does not imply ownership (this means implementations
must not internally call
AHardwareBuffer_lock to implement
vkMapMemory, or assume the application has done so).
Implementations are not required to support linear-tiled images backed by
Android hardware buffers, even if the
AHardwareBuffer has CPU
There is no reliable way to allocate memory in Vulkan that can be exported
AHardwareBuffer with CPU usage.
5) Android may add new
AHardwareBuffer formats and usage flags over
Can reference to them be added to this extension, or do they need a new
RESOLVED: This extension can document the interaction between the new AHB
formats/usages and existing Vulkan features.
No new Vulkan features or implementation requirements can be added.
The extension version number will be incremented when this additional
documentation is added, but the version number does not indicate that an
implementaiton supports Vulkan memory or resources that map to the new
AHardwareBuffer features: support for that must be queried with
vkGetPhysicalDeviceImageFormatProperties2 or is implied by
successfully allocating a
AHardwareBuffer outside of Vulkan that
uses the new feature and has a GPU usage flag.
In essence, these are new features added to a new Android API level, rather than new Vulkan features. The extension will only document how existing Vulkan features map to that new Android feature.
AHardwareBuffer, VkAndroidHardwareBufferFormatPropertiesANDROID, VkAndroidHardwareBufferPropertiesANDROID, VkAndroidHardwareBufferUsageANDROID, VkExternalFormatANDROID, VkImportAndroidHardwareBufferInfoANDROID, VkMemoryGetAndroidHardwareBufferInfoANDROID, vkGetAndroidHardwareBufferPropertiesANDROID, vkGetMemoryAndroidHardwareBufferANDROID
For more information, see the Vulkan Specification
This page is a generated document. Fixes and changes should be made to the generator scripts, not directly.