| Safe Haskell | None |
|---|---|
| Language | Haskell2010 |
Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer
Description
Name
VK_ANDROID_external_memory_android_hardware_buffer - device extension
VK_ANDROID_external_memory_android_hardware_buffer
- Name String
VK_ANDROID_external_memory_android_hardware_buffer
- Extension Type
- Device extension
- Registered Extension Number
- 130
- Revision
- 4
- Extension and Version Dependencies
- Requires Vulkan 1.0
- Requires
VK_KHR_sampler_ycbcr_conversion - Requires
VK_KHR_external_memory - Requires
VK_EXT_queue_family_foreign - Requires
VK_KHR_dedicated_allocation
- Contact
Other Extension Metadata
- Last Modified Date
- 2021-09-30
- IP Status
- No known IP claims.
- Contributors
- Ray Smith, ARM
- Chad Versace, Google
- Jesse Hall, Google
- Tobias Hector, Imagination
- James Jones, NVIDIA
- Tony Zlatinski, NVIDIA
- Matthew Netsch, Qualcomm
- Andrew Garrard, Samsung
Description
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 creating the
AHardwareBuffer externally and importing it.
Some 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.
New Base Types
New Commands
New Structures
MemoryGetAndroidHardwareBufferInfoANDROIDExtending
AndroidHardwareBufferPropertiesANDROID:Extending
ImageCreateInfo,SamplerYcbcrConversionCreateInfo:Extending
ImageFormatProperties2:Extending
MemoryAllocateInfo:
If VK_KHR_format_feature_flags2 is supported:
New Enum Constants
ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSIONExtending
ExternalMemoryHandleTypeFlagBits:Extending
StructureType:STRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_FORMAT_PROPERTIES_ANDROIDSTRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_PROPERTIES_ANDROIDSTRUCTURE_TYPE_ANDROID_HARDWARE_BUFFER_USAGE_ANDROIDSTRUCTURE_TYPE_EXTERNAL_FORMAT_ANDROIDSTRUCTURE_TYPE_IMPORT_ANDROID_HARDWARE_BUFFER_INFO_ANDROIDSTRUCTURE_TYPE_MEMORY_GET_ANDROID_HARDWARE_BUFFER_INFO_ANDROID
If VK_KHR_format_feature_flags2 is supported:
Issues
1) Other external memory objects are represented as weakly-typed handles
(e.g. Win32 HANDLE or
POSIX file descriptor), and require a handle type parameter along with
handles. AHardwareBuffer is strongly typed, so naming the handle type
is redundant. Does symmetry justify adding handle type
parameters/fields anyway?
RESOLVED: No. The handle type is already provided in places that
treat external memory objects generically. 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 AHardwareBuffer image
may depend on native usage flags that do not have corresponding Vulkan
counterparts. Do we provide this information to
createImage somehow, or allow the allocation size
reported by getImageMemoryRequirements
to be approximate?
RESOLVED: Allow the allocation size to be unspecified when
allocating the memory. It has to work this way for exported image memory
anyway, since AHardwareBuffer allocation happens in
allocateMemory, and internally is performed by a
separate HAL, not the Vulkan implementation itself. There is a similar
issue with getImageSubresourceLayout: 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 AHardwareBuffer with AHARDWAREBUFFER_USAGE_CPU_* 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
AHardwareBuffer_lock. 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 mapMemory, 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 usage. There is no reliable way to
allocate memory in Vulkan that can be exported to a AHardwareBuffer
with CPU usage.
5) Android may add new AHardwareBuffer formats and usage flags over
time. Can reference to them be added to this extension, or do they need
a new extension?
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
getPhysicalDeviceImageFormatProperties2
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.
Version History
Revision 4, 2021-09-30 (Jon Leech)
- Add interaction with
VK_KHR_format_feature_flags2tovk.xml
- Add interaction with
Revision 3, 2019-08-27 (Jon Leech)
- Update revision history to correspond to XML version number
Revision 2, 2018-04-09 (Petr Kraus)
- Markup fixes and remove incorrect Draft status
Revision 1, 2018-03-04 (Jesse Hall)
- Initial version
See Also
AHardwareBuffer, AndroidHardwareBufferFormatPropertiesANDROID,
AndroidHardwareBufferPropertiesANDROID,
AndroidHardwareBufferUsageANDROID, ExternalFormatANDROID,
ImportAndroidHardwareBufferInfoANDROID,
MemoryGetAndroidHardwareBufferInfoANDROID,
getAndroidHardwareBufferPropertiesANDROID,
getMemoryAndroidHardwareBufferANDROID
Document Notes
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.
Synopsis
- getAndroidHardwareBufferPropertiesANDROID :: forall a io. (Extendss AndroidHardwareBufferPropertiesANDROID a, PokeChain a, PeekChain a, MonadIO io) => Device -> Ptr AHardwareBuffer -> io (AndroidHardwareBufferPropertiesANDROID a)
- getMemoryAndroidHardwareBufferANDROID :: forall io. MonadIO io => Device -> MemoryGetAndroidHardwareBufferInfoANDROID -> io (Ptr AHardwareBuffer)
- data ImportAndroidHardwareBufferInfoANDROID = ImportAndroidHardwareBufferInfoANDROID {}
- data AndroidHardwareBufferUsageANDROID = AndroidHardwareBufferUsageANDROID {}
- data AndroidHardwareBufferPropertiesANDROID (es :: [Type]) = AndroidHardwareBufferPropertiesANDROID {
- next :: Chain es
- allocationSize :: DeviceSize
- memoryTypeBits :: Word32
- data MemoryGetAndroidHardwareBufferInfoANDROID = MemoryGetAndroidHardwareBufferInfoANDROID {}
- data AndroidHardwareBufferFormatPropertiesANDROID = AndroidHardwareBufferFormatPropertiesANDROID {}
- data ExternalFormatANDROID = ExternalFormatANDROID {}
- data AndroidHardwareBufferFormatProperties2ANDROID = AndroidHardwareBufferFormatProperties2ANDROID {
- format :: Format
- externalFormat :: Word64
- formatFeatures :: FormatFeatureFlags2KHR
- samplerYcbcrConversionComponents :: ComponentMapping
- suggestedYcbcrModel :: SamplerYcbcrModelConversion
- suggestedYcbcrRange :: SamplerYcbcrRange
- suggestedXChromaOffset :: ChromaLocation
- suggestedYChromaOffset :: ChromaLocation
- type ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION = 4
- pattern ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION :: forall a. Integral a => a
- type ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME = "VK_ANDROID_external_memory_android_hardware_buffer"
- pattern ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a
- data AHardwareBuffer
- newtype FormatFeatureFlagBits2KHR where
- FormatFeatureFlagBits2KHR Flags64
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_BLIT_DST_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_MINMAX_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_DISJOINT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXT :: FormatFeatureFlagBits2KHR
- pattern FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR
- type FormatFeatureFlags2KHR = FormatFeatureFlagBits2KHR
- type Flags64 = Word64
Documentation
getAndroidHardwareBufferPropertiesANDROID Source #
Arguments
| :: forall a io. (Extendss AndroidHardwareBufferPropertiesANDROID a, PokeChain a, PeekChain a, MonadIO io) | |
| => Device |
|
| -> Ptr AHardwareBuffer |
|
| -> io (AndroidHardwareBufferPropertiesANDROID a) |
vkGetAndroidHardwareBufferPropertiesANDROID - Get Properties of External Memory Android Hardware Buffers
Return Codes
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
AndroidHardwareBufferPropertiesANDROID, Device
getMemoryAndroidHardwareBufferANDROID Source #
Arguments
| :: forall io. MonadIO io | |
| => Device |
|
| -> MemoryGetAndroidHardwareBufferInfoANDROID |
|
| -> io (Ptr AHardwareBuffer) |
vkGetMemoryAndroidHardwareBufferANDROID - Get an Android hardware buffer for a memory object
Description
Each call to getMemoryAndroidHardwareBufferANDROID must return an
Android hardware buffer with a new reference acquired in addition to the
reference held by the DeviceMemory. To avoid
leaking resources, the application must release the reference by
calling AHardwareBuffer_release when it is no longer needed. When
called with the same handle in
MemoryGetAndroidHardwareBufferInfoANDROID::memory,
getMemoryAndroidHardwareBufferANDROID must return the same Android
hardware buffer object. If the device memory was created by importing an
Android hardware buffer, getMemoryAndroidHardwareBufferANDROID must
return that same Android hardware buffer object.
Return Codes
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
Device,
MemoryGetAndroidHardwareBufferInfoANDROID
data ImportAndroidHardwareBufferInfoANDROID Source #
VkImportAndroidHardwareBufferInfoANDROID - Import memory from an Android hardware buffer
Description
If the allocateMemory command succeeds, the
implementation must acquire a reference to the imported hardware
buffer, which it must release when the device memory object is freed.
If the command fails, the implementation must not retain a reference.
Valid Usage
- If
bufferis notNULL, Android hardware buffers must be supported for import, as reported byExternalImageFormatPropertiesorExternalBufferProperties
- If
bufferis notNULL, it must be a valid Android hardware buffer object withAHardwareBuffer_Desc::usagecompatible with Vulkan as described in Android Hardware Buffers
Valid Usage (Implicit)
-
buffermust be a valid pointer to anAHardwareBuffervalue
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
StructureType
Constructors
| ImportAndroidHardwareBufferInfoANDROID | |
Fields
| |
Instances
data AndroidHardwareBufferUsageANDROID Source #
VkAndroidHardwareBufferUsageANDROID - Struct containing Android hardware buffer usage flags
Description
The androidHardwareBufferUsage field must include Android hardware
buffer usage flags listed in the
AHardwareBuffer Usage Equivalence
table when the corresponding Vulkan image usage or image creation flags
are included in the usage or flags fields of
PhysicalDeviceImageFormatInfo2.
It must include at least one GPU usage flag
(AHARDWAREBUFFER_USAGE_GPU_*), even if none of the corresponding
Vulkan usages or flags are requested.
Note
Requiring at least one GPU usage flag ensures that Android hardware
buffer memory will be allocated in a memory pool accessible to the
Vulkan implementation, and that specializing the memory layout based on
usage flags does not prevent it from being compatible with Vulkan.
Implementations may avoid unnecessary restrictions caused by this
requirement by using vendor usage flags to indicate that only the Vulkan
uses indicated in
ImageFormatProperties2
are required.
Valid Usage (Implicit)
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
StructureType
Constructors
| AndroidHardwareBufferUsageANDROID | |
Fields
| |
Instances
data AndroidHardwareBufferPropertiesANDROID (es :: [Type]) Source #
VkAndroidHardwareBufferPropertiesANDROID - Properties of External Memory Android Hardware Buffers
Valid Usage (Implicit)
- Each
pNextmember of any structure (including this one) in thepNextchain must be eitherNULLor a pointer to a valid instance ofAndroidHardwareBufferFormatProperties2ANDROIDorAndroidHardwareBufferFormatPropertiesANDROID - The
sTypevalue of each struct in thepNextchain must be unique
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
DeviceSize,
StructureType,
getAndroidHardwareBufferPropertiesANDROID
Constructors
| AndroidHardwareBufferPropertiesANDROID | |
Fields
| |
Instances
data MemoryGetAndroidHardwareBufferInfoANDROID Source #
VkMemoryGetAndroidHardwareBufferInfoANDROID - Structure describing an Android hardware buffer memory export operation
Valid Usage
-
EXTERNAL_MEMORY_HANDLE_TYPE_ANDROID_HARDWARE_BUFFER_BIT_ANDROIDmust have been included inExportMemoryAllocateInfo::handleTypeswhenmemorywas created
- If
the
pNextchain of theMemoryAllocateInfoused to allocatememoryincluded aMemoryDedicatedAllocateInfowith non-NULLimagemember, then thatimagemust already be bound tomemory
Valid Usage (Implicit)
-
pNextmust beNULL -
memorymust be a validDeviceMemoryhandle
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
DeviceMemory,
StructureType,
getMemoryAndroidHardwareBufferANDROID
Constructors
| MemoryGetAndroidHardwareBufferInfoANDROID | |
Fields
| |
Instances
data AndroidHardwareBufferFormatPropertiesANDROID Source #
VkAndroidHardwareBufferFormatPropertiesANDROID - Structure describing the image format properties of an Android hardware buffer
Description
If the Android hardware buffer has one of the formats listed in the
Format Equivalence table,
then format must have the equivalent Vulkan format listed in the
table. Otherwise, format may be
FORMAT_UNDEFINED, indicating the Android
hardware buffer can only be used with an external format.
The formatFeatures member must include
FORMAT_FEATURE_SAMPLED_IMAGE_BIT
and at least one of
FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT
or
FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT,
and should include
FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
and
FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT.
Note
The formatFeatures member only indicates the features available when
using an
external-format image
created from the Android hardware buffer. Images from Android hardware
buffers with a format other than
FORMAT_UNDEFINED are subject to the format
capabilities obtained from
getPhysicalDeviceFormatProperties2,
and
getPhysicalDeviceImageFormatProperties2
with appropriate parameters. These sets of features are independent of
each other, e.g. the external format will support sampler Y′CBCR
conversion even if the non-external format does not, and writing to
non-external format images is possible but writing to external format
images is not.
Android hardware buffers with the same external format must have the
same support for
FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT,
FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT,
FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT,
FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT,
FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT,
and
FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT.
in formatFeatures. Other format features may differ between Android
hardware buffers that have the same external format. This allows
applications to use the same
SamplerYcbcrConversion object (and samplers and
pipelines created from them) for any Android hardware buffers that have
the same external format.
If format is not FORMAT_UNDEFINED, then
the value of samplerYcbcrConversionComponents must be valid when
used as the components member of
SamplerYcbcrConversionCreateInfo
with that format. If format is
FORMAT_UNDEFINED, all members of
samplerYcbcrConversionComponents must be the
identity swizzle.
Implementations may not always be able to determine the color model,
numerical range, or chroma offsets of the image contents, so the values
in AndroidHardwareBufferFormatPropertiesANDROID are only suggestions.
Applications should treat these values as sensible defaults to use in
the absence of more reliable information obtained through some other
means. If the underlying physical device is also usable via OpenGL ES
with the
GL_OES_EGL_image_external
extension, the implementation should suggest values that will produce
similar sampled values as would be obtained by sampling the same
external image via samplerExternalOES in OpenGL ES using equivalent
sampler parameters.
Note
Since GL_OES_EGL_image_external does not require the same sampling and conversion calculations as Vulkan does, achieving identical results between APIs may not be possible on some implementations.
Valid Usage (Implicit)
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
ChromaLocation,
ComponentMapping,
Format,
FormatFeatureFlags,
SamplerYcbcrModelConversion,
SamplerYcbcrRange,
StructureType
Constructors
| AndroidHardwareBufferFormatPropertiesANDROID | |
Fields
| |
Instances
data ExternalFormatANDROID Source #
VkExternalFormatANDROID - Structure containing an Android hardware buffer external format
Description
If externalFormat is zero, the effect is as if the
ExternalFormatANDROID structure was not present. Otherwise, the
image will have the specified external format.
Valid Usage (Implicit)
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
StructureType
Constructors
| ExternalFormatANDROID | |
Fields
| |
Instances
data AndroidHardwareBufferFormatProperties2ANDROID Source #
VkAndroidHardwareBufferFormatProperties2ANDROID - Structure describing the image format properties of an Android hardware buffer
Description
The bits reported in formatFeatures must include the bits reported
in the corresponding fields of
AndroidHardwareBufferFormatPropertiesANDROID::formatFeatures.
Valid Usage (Implicit)
See Also
VK_ANDROID_external_memory_android_hardware_buffer,
VK_KHR_format_feature_flags2,
ChromaLocation,
ComponentMapping,
Format,
FormatFeatureFlags2KHR,
SamplerYcbcrModelConversion,
SamplerYcbcrRange,
StructureType
Constructors
| AndroidHardwareBufferFormatProperties2ANDROID | |
Fields
| |
Instances
pattern ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_SPEC_VERSION :: forall a. Integral a => a Source #
type ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME = "VK_ANDROID_external_memory_android_hardware_buffer" Source #
pattern ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME :: forall a. (Eq a, IsString a) => a Source #
data AHardwareBuffer Source #
newtype FormatFeatureFlagBits2KHR Source #
VkFormatFeatureFlagBits2KHR - Bitmask specifying features supported by a buffer
Description
The following bits may be set in linearTilingFeatures and
optimalTilingFeatures, specifying that the features are supported by
images or image views or
sampler Y′CBCR conversion objects
created with the queried
getPhysicalDeviceFormatProperties2::format:
FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHRspecifies that an image view can be sampled from.FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHRspecifies that an image view can be used as a storage image.FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHRspecifies that an image view can be used as storage image that supports atomic operations.FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHRspecifies that an image view can be used as a framebuffer color attachment and as an input attachment.FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHRspecifies that an image view can be used as a framebuffer color attachment that supports blending and as an input attachment.FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHRspecifies that an image view can be used as a framebuffer depth/stencil attachment and as an input attachment.FORMAT_FEATURE_2_BLIT_SRC_BIT_KHRspecifies that an image can be used assrcImagefor thecmdBlitImage2KHRandcmdBlitImagecommands.FORMAT_FEATURE_2_BLIT_DST_BIT_KHRspecifies that an image can be used asdstImagefor thecmdBlitImage2KHRandcmdBlitImagecommands.FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHRspecifies that ifFORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHRis also set, an image view can be used with a sampler that has either ofmagFilterorminFilterset toFILTER_LINEAR, ormipmapModeset toSAMPLER_MIPMAP_MODE_LINEAR. IfFORMAT_FEATURE_2_BLIT_SRC_BIT_KHRis also set, an image can be used as thesrcImagetocmdBlitImage2KHRandcmdBlitImagewith afilterofFILTER_LINEAR. This bit must only be exposed for formats that also support theFORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHRorFORMAT_FEATURE_2_BLIT_SRC_BIT_KHR.If the format being queried is a depth/stencil format, this bit only specifies that the depth aspect (not the stencil aspect) of an image of this format supports linear filtering. Where depth comparison is supported it may be linear filtered whether this bit is present or not, but where this bit is not present the filtered value may be computed in an implementation-dependent manner which differs from the normal rules of linear filtering. The resulting value must be in the range [0,1] and should be proportional to, or a weighted average of, the number of comparison passes or failures.
FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHRspecifies that an image can be used as a source image for copy commands.FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHRspecifies that an image can be used as a destination image for copy commands and clear commands.FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_MINMAX_BIT_KHRspecifiesImagecan be used as a sampled image with a min or maxSamplerReductionMode. This bit must only be exposed for formats that also support theFORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR.FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXTspecifies thatImagecan be used with a sampler that has either ofmagFilterorminFilterset toFILTER_CUBIC_EXT, or be the source image for a blit withfilterset toFILTER_CUBIC_EXT. This bit must only be exposed for formats that also support theFORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR. If the format being queried is a depth/stencil format, this only specifies that the depth aspect is cubic filterable.FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHRspecifies that an application can define a sampler Y′CBCR conversion using this format as a source, and that an image of this format can be used with aSamplerYcbcrConversionCreateInfoxChromaOffsetand/oryChromaOffsetofCHROMA_LOCATION_MIDPOINT. Otherwise bothxChromaOffsetandyChromaOffsetmust beCHROMA_LOCATION_COSITED_EVEN. If a format does not incorporate chroma downsampling (it is not a “422” or “420” format) but the implementation supports sampler Y′CBCR conversion for this format, the implementation must setFORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR.FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHRspecifies that an application can define a sampler Y′CBCR conversion using this format as a source, and that an image of this format can be used with aSamplerYcbcrConversionCreateInfoxChromaOffsetand/oryChromaOffsetofCHROMA_LOCATION_COSITED_EVEN. Otherwise bothxChromaOffsetandyChromaOffsetmust beCHROMA_LOCATION_MIDPOINT. If neitherFORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHRnorFORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHRis set, the application must not define a sampler Y′CBCR conversion using this format as a source.FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHRspecifies that an application can define a sampler Y′CBCR conversion using this format as a source withchromaFilterset toFILTER_LINEAR.FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHRspecifies that the format can have different chroma, min, and mag filters.FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHRspecifies that reconstruction is explicit, as described in https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#textures-chroma-reconstruction. If this bit is not present, reconstruction is implicit by default.FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHRspecifies that reconstruction can be forcibly made explicit by settingSamplerYcbcrConversionCreateInfo::forceExplicitReconstructiontoTRUE. If the format being queried supportsFORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHRit must also supportFORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR.FORMAT_FEATURE_2_DISJOINT_BIT_KHRspecifies that a multi-planar image can have theIMAGE_CREATE_DISJOINT_BITset during image creation. An implementation must not setFORMAT_FEATURE_2_DISJOINT_BIT_KHRfor single-plane formats.FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXTspecifies that an image view can be used as a fragment density map attachment.FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHRspecifies that an image view can be used as a fragment shading rate attachment. An implementation must not set this feature for formats with numeric type other than*UINT, or set it as a buffer feature.FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHRspecifies that image views created with this format can be used as storage images for read operations without specifying a format.FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHRspecifies that image views created with this format can be used as storage images for write operations without specifying a format.FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHRspecifies that image views created with this format can be used for depth comparison performed byOpImage*Drefinstructions.
The following bits may be set in bufferFeatures, specifying that the
features are supported by buffers or
buffer views created with the queried
getPhysicalDeviceFormatProperties2::format:
FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHRspecifies that the format can be used to create a buffer view that can be bound to aDESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFERdescriptor.FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHRspecifies that the format can be used to create a buffer view that can be bound to aDESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFERdescriptor.FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHRspecifies that atomic operations are supported onDESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFERwith this format.FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHRspecifies that the format can be used as a vertex attribute format (VertexInputAttributeDescription::format).FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHRspecifies that the format can be used as the vertex format when creating an acceleration structure (AccelerationStructureGeometryTrianglesDataKHR::vertexFormat). This format can also be used as the vertex format in host memory when doing host acceleration structure builds.
See Also
Constructors
| FormatFeatureFlagBits2KHR Flags64 |
Bundled Patterns
Instances
type Flags64 = Word64 Source #
VkFlags64 - Vulkan 64-bit bitmasks
Description
When the 31 bits available in Flags are insufficient, the Flags64
type can be passed to commands and structures to represent up to 64
options. Flags64 is not used directly in the API. Instead, a
Vk*Flags2 type which is an alias of Flags64, and whose name matches
the corresponding Vk*FlagBits2 that are valid for that type, is used.
Any Vk*Flags2 member or parameter used in the API as an input must
be a valid combination of bit flags. A valid combination is either zero
or the bitwise OR of valid bit flags. A bit flag is valid if:
- The bit flag is defined as part of the
Vk*FlagBits2type, where the bits type is obtained by taking the flag type and replacing the trailingFlags2withFlagBits2. For example, a flag value of typeAccessFlags2KHRmust contain only bit flags defined byAccessFlagBits2KHR. - The flag is allowed in the context in which it is being used. For example, in some cases, certain bit flags or combinations of bit flags are mutually exclusive.
Any Vk*Flags2 member or parameter returned from a query command or
otherwise output from Vulkan to the application may contain bit flags
undefined in its corresponding Vk*FlagBits2 type. An application
cannot rely on the state of these unspecified bits.
Note
Both the Vk*FlagBits2 type, and the individual bits defined for that
type, are defined as uint64_t integers in the C API. This is in
contrast to the 32-bit types, where the Vk*FlagBits type is defined as
a C enum and the individual bits as enumerants belonging to that
enum. As a result, there is less compile-time type checking possible
for the 64-bit types. This is unavoidable since there is no sufficiently
portable way to define a 64-bit enum type in C99.