vulkan-3.13.3: Bindings to the Vulkan graphics API.
Safe HaskellNone
LanguageHaskell2010

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

If VK_KHR_format_feature_flags2 is supported:

New Enum Constants

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_flags2 to vk.xml
  • 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

Documentation

getAndroidHardwareBufferPropertiesANDROID Source #

Arguments

:: forall a io. (Extendss AndroidHardwareBufferPropertiesANDROID a, PokeChain a, PeekChain a, MonadIO io) 
=> Device

device is the logical device that will be importing buffer.

device must be a valid Device handle

-> Ptr AHardwareBuffer

buffer is the Android hardware buffer which will be imported.

buffer must be a valid Android hardware buffer object with at least one of the AHARDWAREBUFFER_USAGE_GPU_* flags in its AHardwareBuffer_Desc::usage

buffer must be a valid pointer to a valid AHardwareBuffer value

-> io (AndroidHardwareBufferPropertiesANDROID a) 

vkGetAndroidHardwareBufferPropertiesANDROID - Get Properties of External Memory Android Hardware Buffers

Return Codes

Success
Failure

See Also

VK_ANDROID_external_memory_android_hardware_buffer, AndroidHardwareBufferPropertiesANDROID, Device

getMemoryAndroidHardwareBufferANDROID Source #

Arguments

:: forall io. MonadIO io 
=> Device

device is the logical device that created the device memory being exported.

device must be a valid Device handle

-> MemoryGetAndroidHardwareBufferInfoANDROID

pInfo is a pointer to a MemoryGetAndroidHardwareBufferInfoANDROID structure containing parameters of the export operation.

pInfo must be a valid pointer to a valid MemoryGetAndroidHardwareBufferInfoANDROID structure

-> 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

Success
Failure

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 buffer is not NULL, it must be a valid Android hardware buffer object with AHardwareBuffer_Desc::usage compatible with Vulkan as described in Android Hardware Buffers

Valid Usage (Implicit)

See Also

VK_ANDROID_external_memory_android_hardware_buffer, StructureType

Constructors

ImportAndroidHardwareBufferInfoANDROID 

Fields

Instances

Instances details
Eq ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Show ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero ImportAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

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

Instances details
Eq AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Show AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero AndroidHardwareBufferUsageANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

data AndroidHardwareBufferPropertiesANDROID (es :: [Type]) Source #

VkAndroidHardwareBufferPropertiesANDROID - Properties of External Memory Android Hardware Buffers

Valid Usage (Implicit)

See Also

VK_ANDROID_external_memory_android_hardware_buffer, DeviceSize, StructureType, getAndroidHardwareBufferPropertiesANDROID

Constructors

AndroidHardwareBufferPropertiesANDROID 

Fields

  • next :: Chain es

    pNext is NULL or a pointer to a structure extending this structure.

  • allocationSize :: DeviceSize

    allocationSize is the size of the external memory

  • memoryTypeBits :: Word32

    memoryTypeBits is a bitmask containing one bit set for every memory type which the specified Android hardware buffer can be imported as.

Instances

Instances details
Extensible AndroidHardwareBufferPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Show (Chain es) => Show (AndroidHardwareBufferPropertiesANDROID es) Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

(Extendss AndroidHardwareBufferPropertiesANDROID es, PeekChain es) => FromCStruct (AndroidHardwareBufferPropertiesANDROID es) Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

(Extendss AndroidHardwareBufferPropertiesANDROID es, PokeChain es) => ToCStruct (AndroidHardwareBufferPropertiesANDROID es) Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

es ~ ('[] :: [Type]) => Zero (AndroidHardwareBufferPropertiesANDROID es) Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

data MemoryGetAndroidHardwareBufferInfoANDROID Source #

VkMemoryGetAndroidHardwareBufferInfoANDROID - Structure describing an Android hardware buffer memory export operation

Valid Usage

Valid Usage (Implicit)

  • pNext must be NULL
  • memory must be a valid DeviceMemory handle

See Also

VK_ANDROID_external_memory_android_hardware_buffer, DeviceMemory, StructureType, getMemoryAndroidHardwareBufferANDROID

Constructors

MemoryGetAndroidHardwareBufferInfoANDROID 

Fields

  • memory :: DeviceMemory

    memory is the memory object from which the Android hardware buffer will be exported.

Instances

Instances details
Eq MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Show MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero MemoryGetAndroidHardwareBufferInfoANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

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

Instances details
Show AndroidHardwareBufferFormatPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable AndroidHardwareBufferFormatPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct AndroidHardwareBufferFormatPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct AndroidHardwareBufferFormatPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero AndroidHardwareBufferFormatPropertiesANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

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

Instances details
Eq ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Show ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero ExternalFormatANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

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

Instances details
Show AndroidHardwareBufferFormatProperties2ANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Storable AndroidHardwareBufferFormatProperties2ANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

FromCStruct AndroidHardwareBufferFormatProperties2ANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

ToCStruct AndroidHardwareBufferFormatProperties2ANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

Zero AndroidHardwareBufferFormatProperties2ANDROID Source # 
Instance details

Defined in Vulkan.Extensions.VK_ANDROID_external_memory_android_hardware_buffer

type ANDROID_EXTERNAL_MEMORY_ANDROID_HARDWARE_BUFFER_EXTENSION_NAME = "VK_ANDROID_external_memory_android_hardware_buffer" 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:

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:

See Also

VK_KHR_format_feature_flags2

Bundled Patterns

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR specifies that an image view can be sampled from.

pattern FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_IMAGE_BIT_KHR specifies that an image view can be used as a storage image.

pattern FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_IMAGE_ATOMIC_BIT_KHR specifies that an image view can be used as storage image that supports atomic operations.

pattern FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_UNIFORM_TEXEL_BUFFER_BIT_KHR specifies that the format can be used to create a buffer view that can be bound to a DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER descriptor.

pattern FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_BIT_KHR specifies that the format can be used to create a buffer view that can be bound to a DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER descriptor.

pattern FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_TEXEL_BUFFER_ATOMIC_BIT_KHR specifies that atomic operations are supported on DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER with this format.

pattern FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_VERTEX_BUFFER_BIT_KHR specifies that the format can be used as a vertex attribute format (VertexInputAttributeDescription::format).

pattern FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_COLOR_ATTACHMENT_BIT_KHR specifies that an image view can be used as a framebuffer color attachment and as an input attachment.

pattern FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_COLOR_ATTACHMENT_BLEND_BIT_KHR specifies that an image view can be used as a framebuffer color attachment that supports blending and as an input attachment.

pattern FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_DEPTH_STENCIL_ATTACHMENT_BIT_KHR specifies that an image view can be used as a framebuffer depth/stencil attachment and as an input attachment.

pattern FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR specifies that an image can be used as srcImage for the cmdBlitImage2KHR and cmdBlitImage commands.

pattern FORMAT_FEATURE_2_BLIT_DST_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_BLIT_DST_BIT_KHR specifies that an image can be used as dstImage for the cmdBlitImage2KHR and cmdBlitImage commands.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_LINEAR_BIT_KHR specifies that if FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR is also set, an image view can be used with a sampler that has either of magFilter or minFilter set to FILTER_LINEAR, or mipmapMode set to SAMPLER_MIPMAP_MODE_LINEAR. If FORMAT_FEATURE_2_BLIT_SRC_BIT_KHR is also set, an image can be used as the srcImage to cmdBlitImage2KHR and cmdBlitImage with a filter of FILTER_LINEAR. This bit must only be exposed for formats that also support the FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR or FORMAT_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.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT specifies that Image can be used with a sampler that has either of magFilter or minFilter set to FILTER_CUBIC_EXT, or be the source image for a blit with filter set to FILTER_CUBIC_EXT. This bit must only be exposed for formats that also support the FORMAT_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.

pattern FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_TRANSFER_SRC_BIT_KHR specifies that an image can be used as a source image for copy commands.

pattern FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_TRANSFER_DST_BIT_KHR specifies that an image can be used as a destination image for copy commands and clear commands.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_MINMAX_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_FILTER_MINMAX_BIT_KHR specifies Image can be used as a sampled image with a min or max SamplerReductionMode. This bit must only be exposed for formats that also support the FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT_KHR.

pattern FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR specifies 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 a SamplerYcbcrConversionCreateInfo xChromaOffset and/or yChromaOffset of CHROMA_LOCATION_MIDPOINT. Otherwise both xChromaOffset and yChromaOffset must be CHROMA_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 set FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT_KHR specifies that an application can define a sampler Y′CBCR conversion using this format as a source with chromaFilter set to FILTER_LINEAR.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT_KHR specifies that the format can have different chroma, min, and mag filters.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR specifies 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.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR specifies that reconstruction can be forcibly made explicit by setting SamplerYcbcrConversionCreateInfo::forceExplicitReconstruction to TRUE. If the format being queried supports FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT_KHR it must also support FORMAT_FEATURE_2_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT_KHR.

pattern FORMAT_FEATURE_2_DISJOINT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_DISJOINT_BIT_KHR specifies that a multi-planar image can have the IMAGE_CREATE_DISJOINT_BIT set during image creation. An implementation must not set FORMAT_FEATURE_2_DISJOINT_BIT_KHR for single-plane formats.

pattern FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR specifies 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 a SamplerYcbcrConversionCreateInfo xChromaOffset and/or yChromaOffset of CHROMA_LOCATION_COSITED_EVEN. Otherwise both xChromaOffset and yChromaOffset must be CHROMA_LOCATION_MIDPOINT. If neither FORMAT_FEATURE_2_COSITED_CHROMA_SAMPLES_BIT_KHR nor FORMAT_FEATURE_2_MIDPOINT_CHROMA_SAMPLES_BIT_KHR is set, the application must not define a sampler Y′CBCR conversion using this format as a source.

pattern FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_READ_WITHOUT_FORMAT_BIT_KHR specifies that image views created with this format can be used as storage images for read operations without specifying a format.

pattern FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_STORAGE_WRITE_WITHOUT_FORMAT_BIT_KHR specifies that image views created with this format can be used as storage images for write operations without specifying a format.

pattern FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_SAMPLED_IMAGE_DEPTH_COMPARISON_BIT_KHR specifies that image views created with this format can be used for depth comparison performed by OpImage*Dref instructions.

pattern FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_FRAGMENT_SHADING_RATE_ATTACHMENT_BIT_KHR specifies 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.

pattern FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXT :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_FRAGMENT_DENSITY_MAP_BIT_EXT specifies that an image view can be used as a fragment density map attachment.

pattern FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR :: FormatFeatureFlagBits2KHR

FORMAT_FEATURE_2_ACCELERATION_STRUCTURE_VERTEX_BUFFER_BIT_KHR specifies 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.

Instances

Instances details
Eq FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Ord FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Read FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Show FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Storable FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Bits FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Methods

(.&.) :: FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR #

(.|.) :: FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR #

xor :: FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR #

complement :: FormatFeatureFlagBits2KHR -> FormatFeatureFlagBits2KHR #

shift :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

rotate :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

zeroBits :: FormatFeatureFlagBits2KHR #

bit :: Int -> FormatFeatureFlagBits2KHR #

setBit :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

clearBit :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

complementBit :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

testBit :: FormatFeatureFlagBits2KHR -> Int -> Bool #

bitSizeMaybe :: FormatFeatureFlagBits2KHR -> Maybe Int #

bitSize :: FormatFeatureFlagBits2KHR -> Int #

isSigned :: FormatFeatureFlagBits2KHR -> Bool #

shiftL :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

unsafeShiftL :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

shiftR :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

unsafeShiftR :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

rotateL :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

rotateR :: FormatFeatureFlagBits2KHR -> Int -> FormatFeatureFlagBits2KHR #

popCount :: FormatFeatureFlagBits2KHR -> Int #

FiniteBits FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

Zero FormatFeatureFlagBits2KHR Source # 
Instance details

Defined in Vulkan.Extensions.VK_KHR_acceleration_structure

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*FlagBits2 type, where the bits type is obtained by taking the flag type and replacing the trailing Flags2 with FlagBits2. For example, a flag value of type AccessFlags2KHR must contain only bit flags defined by AccessFlagBits2KHR.
  • 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.

See Also

VK_KHR_synchronization2, Flags