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

Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Description

Name

VK_EXT_image_drm_format_modifier - device extension

VK_EXT_image_drm_format_modifier

Name String
VK_EXT_image_drm_format_modifier
Extension Type
Device extension
Registered Extension Number
159
Revision
2
Extension and Version Dependencies
  • Requires Vulkan 1.0
  • Requires VK_KHR_bind_memory2
  • Requires VK_KHR_get_physical_device_properties2
  • Requires VK_KHR_image_format_list
  • Requires VK_KHR_sampler_ycbcr_conversion
Contact

Other Extension Metadata

Last Modified Date
2021-09-30
IP Status
No known IP claims.
Contributors
  • Antoine Labour, Google
  • Bas Nieuwenhuizen, Google
  • Chad Versace, Google
  • James Jones, NVIDIA
  • Jason Ekstrand, Intel
  • Jőrg Wagner, ARM
  • Kristian Høgsberg Kristensen, Google
  • Ray Smith, ARM

Description

This extension provides the ability to use DRM format modifiers with images, enabling Vulkan to better integrate with the Linux ecosystem of graphics, video, and display APIs.

Its functionality closely overlaps with EGL_EXT_image_dma_buf_import_modifiers2^ and EGL_MESA_image_dma_buf_export3^. Unlike the EGL extensions, this extension does not require the use of a specific handle type (such as a dma_buf) for external memory and provides more explicit control of image creation.

Introduction to DRM Format Modifiers

A DRM format modifier is a 64-bit, vendor-prefixed, semi-opaque unsigned integer. Most modifiers represent a concrete, vendor-specific tiling format for images. Some exceptions are DRM_FORMAT_MOD_LINEAR (which is not vendor-specific); DRM_FORMAT_MOD_NONE (which is an alias of DRM_FORMAT_MOD_LINEAR due to historical accident); and DRM_FORMAT_MOD_INVALID (which does not represent a tiling format). The modifier’s vendor prefix consists of the 8 most significant bits. The canonical list of modifiers and vendor prefixes is found in drm_fourcc.h in the Linux kernel source. The other dominant source of modifiers are vendor kernel trees.

One goal of modifiers in the Linux ecosystem is to enumerate for each vendor a reasonably sized set of tiling formats that are appropriate for images shared across processes, APIs, and/or devices, where each participating component may possibly be from different vendors. A non-goal is to enumerate all tiling formats supported by all vendors. Some tiling formats used internally by vendors are inappropriate for sharing; no modifiers should be assigned to such tiling formats.

Modifier values typically do not describe memory layouts. More precisely, a modifier's lower 56 bits usually have no structure. Instead, modifiers name memory layouts; they name a small set of vendor-preferred layouts for image sharing. As a consequence, in each vendor namespace the modifier values are often sequentially allocated starting at 1.

Each modifier is usually supported by a single vendor and its name matches the pattern {VENDOR}_FORMAT_MOD_* or DRM_FORMAT_MOD_{VENDOR}_*. Examples are I915_FORMAT_MOD_X_TILED and DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED. An exception is DRM_FORMAT_MOD_LINEAR, which is supported by most vendors.

Many APIs in Linux use modifiers to negotiate and specify the memory layout of shared images. For example, a Wayland compositor and Wayland client may, by relaying modifiers over the Wayland protocol zwp_linux_dmabuf_v1, negotiate a vendor-specific tiling format for a shared wl_buffer. The client may allocate the underlying memory for the wl_buffer with GBM, providing the chosen modifier to gbm_bo_create_with_modifiers. The client may then import the wl_buffer into Vulkan for producing image content, providing the resource’s dma_buf to ImportMemoryFdInfoKHR and its modifier to ImageDrmFormatModifierExplicitCreateInfoEXT. The compositor may then import the wl_buffer into OpenGL for sampling, providing the resource’s dma_buf and modifier to eglCreateImage. The compositor may also bypass OpenGL and submit the wl_buffer directly to the kernel’s display API, providing the dma_buf and modifier through drm_mode_fb_cmd2.

Format Translation

Modifier-capable APIs often pair modifiers with DRM formats, which are defined in drm_fourcc.h. However, VK_EXT_image_drm_format_modifier uses Format instead of DRM formats. The application must convert between Format and DRM format when it sends or receives a DRM format to or from an external API.

The mapping from Format to DRM format is lossy. Therefore, when receiving a DRM format from an external API, often the application must use information from the external API to accurately map the DRM format to a Format. For example, DRM formats do not distinguish between RGB and sRGB (as of 2018-03-28); external information is required to identify the image’s colorspace.

The mapping between Format and DRM format is also incomplete. For some DRM formats there exist no corresponding Vulkan format, and for some Vulkan formats there exist no corresponding DRM format.

Usage Patterns

Three primary usage patterns are intended for this extension:

  • Negotiation. The application negotiates with modifier-aware, external components to determine sets of image creation parameters supported among all components.

    In the Linux ecosystem, the negotiation usually assumes the image is a 2D, single-sampled, non-mipmapped, non-array image; this extension permits that assumption but does not require it. The result of the negotiation usually resembles a set of tuples such as /(drmFormat, drmFormatModifier)/, where each participating component supports all tuples in the set.

    Many details of this negotiation—such as the protocol used during negotiation, the set of image creation parameters expressable in the protocol, and how the protocol chooses which process and which API will create the image—are outside the scope of this specification.

    In this extension, getPhysicalDeviceFormatProperties2 with DrmFormatModifierPropertiesListEXT serves a primary role during the negotiation, and getPhysicalDeviceImageFormatProperties2 with PhysicalDeviceImageDrmFormatModifierInfoEXT serves a secondary role.

  • Import. The application imports an image with a modifier.

    In this pattern, the application receives from an external source the image’s memory and its creation parameters, which are often the result of the negotiation described above. Some image creation parameters are implicitly defined by the external source; for example, IMAGE_TYPE_2D is often assumed. Some image creation parameters are usually explicit, such as the image’s format, drmFormatModifier, and extent; and each plane’s offset and rowPitch.

    Before creating the image, the application first verifies that the physical device supports the received creation parameters by querying getPhysicalDeviceFormatProperties2 with DrmFormatModifierPropertiesListEXT and getPhysicalDeviceImageFormatProperties2 with PhysicalDeviceImageDrmFormatModifierInfoEXT. Then the application creates the image by chaining ImageDrmFormatModifierExplicitCreateInfoEXT and ExternalMemoryImageCreateInfo onto ImageCreateInfo.

  • Export. The application creates an image and allocates its memory. Then the application exports to modifier-aware consumers the image’s memory handles; its creation parameters; its modifier; and the offset, size, and rowPitch of each memory plane.

    In this pattern, the Vulkan device is the authority for the image; it is the allocator of the image’s memory and the decider of the image’s creation parameters. When choosing the image’s creation parameters, the application usually chooses a tuple /(format, drmFormatModifier)/ from the result of the negotiation described above. The negotiation’s result often contains multiple tuples that share the same format but differ in their modifier. In this case, the application should defer the choice of the image’s modifier to the Vulkan implementation by providing all such modifiers to ImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers; and the implementation should choose from pDrmFormatModifiers the optimal modifier in consideration with the other image parameters.

    The application creates the image by chaining ImageDrmFormatModifierListCreateInfoEXT and ExternalMemoryImageCreateInfo onto ImageCreateInfo. The protocol and APIs by which the application will share the image with external consumers will likely determine the value of ExternalMemoryImageCreateInfo::handleTypes. The implementation chooses for the image an optimal modifier from ImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers. The application then queries the implementation-chosen modifier with getImageDrmFormatModifierPropertiesEXT, and queries the memory layout of each plane with getImageSubresourceLayout.

    The application then allocates the image’s memory with MemoryAllocateInfo, adding chained extending structures for external memory; binds it to the image; and exports the memory, for example, with getMemoryFdKHR.

    Finally, the application sends the image’s creation parameters, its modifier, its per-plane memory layout, and the exported memory handle to the external consumers. The details of how the application transmits this information to external consumers is outside the scope of this specification.

Prior Art

Extension EGL_EXT_image_dma_buf_import1^ introduced the ability to create an EGLImage by importing for each plane a dma_buf, offset, and row pitch.

Later, extension EGL_EXT_image_dma_buf_import_modifiers2^ introduced the ability to query which combination of formats and modifiers the implementation supports and to specify modifiers during creation of the EGLImage.

Extension EGL_MESA_image_dma_buf_export3^ is the inverse of EGL_EXT_image_dma_buf_import_modifiers.

The Linux kernel modesetting API (KMS), when configuring the display’s framebuffer with struct drm_mode_fb_cmd24^, allows one to specify the frambuffer’s modifier as well as a per-plane memory handle, offset, and row pitch.

GBM, a graphics buffer manager for Linux, allows creation of a gbm_bo (that is, a graphics buffer object) by importing data similar to that in EGL_EXT_image_dma_buf_import_modifiers1^; and symmetrically allows exporting the same data from the gbm_bo. See the references to modifier and plane in gbm.h5^.

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) Should this extension define a single DRM format modifier per Image? Or define one per plane?

+

RESOLVED: There exists a single DRM format modifier per Image.

DISCUSSION: Prior art, such as EGL_EXT_image_dma_buf_import_modifiers2^, struct drm_mode_fb_cmd24^, and struct gbm_import_fd_modifier_data5^, allows defining one modifier per plane. However, developers of the GBM and kernel APIs concede it was a mistake. Beginning in Linux 4.10, the kernel requires that the application provide the same DRM format modifier for each plane. (See Linux commit bae781b259269590109e8a4a8227331362b88212). And GBM provides an entry point, gbm_bo_get_modifier, for querying the modifier of the image but does not provide one to query the modifier of individual planes.

2) When creating an image with ImageDrmFormatModifierExplicitCreateInfoEXT, which is typically used when importing an image, should the application explicitly provide the size of each plane?

+

RESOLVED: No. The application must not provide the size. To enforce this, the API requires that ImageDrmFormatModifierExplicitCreateInfoEXT::pPlaneLayouts->size must be 0.

DISCUSSION: Prior art, such as EGL_EXT_image_dma_buf_import_modifiers2^, struct drm_mode_fb_cmd24^, and struct gbm_import_fd_modifier_data5^, omits from the API the size of each plane. Instead, the APIs infer each plane’s size from the import parameters, which include the image’s pixel format and a dma_buf, offset, and row pitch for each plane.

However, Vulkan differs from EGL and GBM with regards to image creation in the following ways:

  • Undedicated allocation by default. When importing or exporting a set of dma_bufs as an EGLImage or gbm_bo, common practice mandates that each dma_buf’s memory be dedicated (in the sense of VK_KHR_dedicated_allocation) to the image (though not necessarily dedicated to a single plane). In particular, neither the GBM documentation nor the EGL extension specifications explicitly state this requirement, but in light of common practice this is likely due to under-specification rather than intentional omission. In contrast, VK_EXT_image_drm_format_modifier permits, but does not require, the implementation to require dedicated allocations for images created with IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT.
  • Separation of image creation and memory allocation. When importing a set of dma_bufs as an EGLImage or gbm_bo, EGL and GBM create the image resource and bind it to memory (the dma_bufs) simultaneously. This allows EGL and GBM to query each dma_buf’s size during image creation. In Vulkan, image creation and memory allocation are independent unless a dedicated allocation is used (as in VK_KHR_dedicated_allocation). Therefore, without requiring dedicated allocation, Vulkan cannot query the size of each dma_buf (or other external handle) when calculating the image’s memory layout. Even if dedication allocation were required, Vulkan cannot calculate the image’s memory layout until after the image is bound to its dma_ufs.

The above differences complicate the potential inference of plane size in Vulkan. Consider the following problematic cases:

  • Padding. Some plane of the image may require implementation-dependent padding.
  • Metadata. For some modifiers, the image may have a metadata plane which requires a non-trivial calculation to determine its size.
  • Mipmapped, array, and 3D images. The implementation may support IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT for images whose mipLevels, arrayLayers, or depth is greater than 1. For such images with certain modifiers, the calculation of each plane’s size may be non-trivial.

However, an application-provided plane size solves none of the above problems.

For simplicity, consider an external image with a single memory plane. The implementation is obviously capable calculating the image’s size when its tiling is IMAGE_TILING_OPTIMAL. Likewise, any reasonable implementation is capable of calculating the image’s size when its tiling uses a supported modifier.

Suppose that the external image’s size is smaller than the implementation-calculated size. If the application provided the external image’s size to createImage, the implementation would observe the mismatched size and recognize its inability to comprehend the external image’s layout (unless the implementation used the application-provided size to select a refinement of the tiling layout indicated by the modifier, which is strongly discouraged). The implementation would observe the conflict, and reject image creation with ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On the other hand, if the application did not provide the external image’s size to createImage, then the application would observe after calling getImageMemoryRequirements that the external image’s size is less than the size required by the implementation. The application would observe the conflict and refuse to bind the Image to the external memory. In both cases, the result is explicit failure.

Suppose that the external image’s size is larger than the implementation-calculated size. If the application provided the external image’s size to createImage, for reasons similar to above the implementation would observe the mismatched size and recognize its inability to comprehend the image data residing in the extra size. The implementation, however, must assume that image data resides in the entire size provided by the application. The implementation would observe the conflict and reject image creation with ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. On the other hand, if the application did not provide the external image’s size to createImage, then the application would observe after calling getImageMemoryRequirements that the external image’s size is larger than the implementation-usable size. The application would observe the conflict and refuse to bind the Image to the external memory. In both cases, the result is explicit failure.

Therefore, an application-provided size provides no benefit, and this extension should not require it. This decision renders SubresourceLayout::size an unused field during image creation, and thus introduces a risk that implementations may require applications to submit sideband creation parameters in the unused field. To prevent implementations from relying on sideband data, this extension requires the application to set size to 0.

References

  1. EGL_EXT_image_dma_buf_import
  1. EGL_EXT_image_dma_buf_import_modifiers
  2. EGL_MESA_image_dma_buf_export
  3. <https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_mode.h?id=refs/tags/v4.10#n392 struct drm_mode_fb_cmd2>
  4. gbm.h

Version History

  • Revision 1, 2018-08-29 (Chad Versace)

    • First stable revision
  • Revision 2, 2021-09-30 (Jon Leech)

    • Add interaction with VK_KHR_format_feature_flags2 to vk.xml

See Also

DrmFormatModifierPropertiesEXT, DrmFormatModifierPropertiesListEXT, ImageDrmFormatModifierExplicitCreateInfoEXT, ImageDrmFormatModifierListCreateInfoEXT, ImageDrmFormatModifierPropertiesEXT, PhysicalDeviceImageDrmFormatModifierInfoEXT, getImageDrmFormatModifierPropertiesEXT

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

getImageDrmFormatModifierPropertiesEXT Source #

Arguments

:: forall io. MonadIO io 
=> Device

device is the logical device that owns the image.

device must be a valid Device handle

-> Image

image is the queried image.

image must have been created with tiling equal to IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT

image must be a valid Image handle

image must have been created, allocated, or retrieved from device

-> io ImageDrmFormatModifierPropertiesEXT 

vkGetImageDrmFormatModifierPropertiesEXT - Returns an image’s DRM format modifier

Return Codes

Success
Failure

See Also

VK_EXT_image_drm_format_modifier, Device, Image, ImageDrmFormatModifierPropertiesEXT

data DrmFormatModifierPropertiesListEXT Source #

VkDrmFormatModifierPropertiesListEXT - Structure specifying the list of DRM format modifiers supported for a format

Description

If pDrmFormatModifierProperties is NULL, then the function returns in drmFormatModifierCount the number of modifiers compatible with the queried format. Otherwise, the application must set drmFormatModifierCount to the length of the array pDrmFormatModifierProperties; the function will write at most drmFormatModifierCount elements to the array, and will return in drmFormatModifierCount the number of elements written.

Among the elements in array pDrmFormatModifierProperties, each returned drmFormatModifier must be unique.

Valid Usage (Implicit)

See Also

VK_EXT_image_drm_format_modifier, DrmFormatModifierPropertiesEXT, StructureType

Constructors

DrmFormatModifierPropertiesListEXT 

Fields

Instances

Instances details
Eq DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Show DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Storable DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero DrmFormatModifierPropertiesListEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data DrmFormatModifierPropertiesEXT Source #

VkDrmFormatModifierPropertiesEXT - Structure specifying properties of a format when combined with a DRM format modifier

Description

The returned drmFormatModifierTilingFeatures must contain at least one bit.

The implementation must not return DRM_FORMAT_MOD_INVALID in drmFormatModifier.

An image’s memory planecount (as returned by drmFormatModifierPlaneCount) is distinct from its format planecount (in the sense of multi-planar Y′CBCR formats). In ImageAspectFlags, each VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT represents a memory plane and each VK_IMAGE_ASPECT_PLANE_i_BIT a format plane.

An image’s set of format planes is an ordered partition of the image’s content into separable groups of format components. The ordered partition is encoded in the name of each Format. For example, FORMAT_G8_B8R8_2PLANE_420_UNORM contains two format planes; the first plane contains the green component and the second plane contains the blue component and red component. If the format name does not contain PLANE, then the format contains a single plane; for example, FORMAT_R8G8B8A8_UNORM. Some commands, such as cmdCopyBufferToImage, do not operate on all format components in the image, but instead operate only on the format planes explicitly chosen by the application and operate on each format plane independently.

An image’s set of memory planes is an ordered partition of the image’s memory rather than the image’s content. Each memory plane is a contiguous range of memory. The union of an image’s memory planes is not necessarily contiguous.

If an image is linear, then the partition is the same for memory planes and for /format planes/. Therefore, if the returned drmFormatModifier is DRM_FORMAT_MOD_LINEAR, then drmFormatModifierPlaneCount must equal the format planecount, and drmFormatModifierTilingFeatures must be identical to the FormatProperties2::linearTilingFeatures returned in the same pNext chain.

If an image is non-linear, then the partition of the image’s memory into memory planes is implementation-specific and may be unrelated to the partition of the image’s content into format planes. For example, consider an image whose format is FORMAT_G8_B8_R8_3PLANE_420_UNORM, tiling is IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, whose drmFormatModifier is not DRM_FORMAT_MOD_LINEAR, and flags lacks IMAGE_CREATE_DISJOINT_BIT. The image has 3 format planes, and commands such cmdCopyBufferToImage act on each format plane independently as if the data of each format plane were separable from the data of the other planes. In a straightforward implementation, the implementation may store the image’s content in 3 adjacent memory planes where each memory plane corresponds exactly to a format plane. However, the implementation may also store the image’s content in a single memory plane where all format components are combined using an implementation-private block-compressed format; or the implementation may store the image’s content in a collection of 7 adjacent memory planes using an implementation-private sharding technique. Because the image is non-linear and non-disjoint, the implementation has much freedom when choosing the image’s placement in memory.

The memory planecount applies to function parameters and structures only when the API specifies an explicit requirement on drmFormatModifierPlaneCount. In all other cases, the /memory planecount/ is ignored.

See Also

VK_EXT_image_drm_format_modifier, DrmFormatModifierPropertiesListEXT, FormatFeatureFlags

Constructors

DrmFormatModifierPropertiesEXT 

Fields

Instances

Instances details
Eq DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Show DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Storable DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero DrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data PhysicalDeviceImageDrmFormatModifierInfoEXT Source #

VkPhysicalDeviceImageDrmFormatModifierInfoEXT - Structure specifying a DRM format modifier as image creation parameter

Description

If the drmFormatModifier is incompatible with the parameters specified in PhysicalDeviceImageFormatInfo2 and its pNext chain, then getPhysicalDeviceImageFormatProperties2 returns ERROR_FORMAT_NOT_SUPPORTED. The implementation must support the query of any drmFormatModifier, including unknown and invalid modifier values.

Valid Usage

  • If sharingMode is SHARING_MODE_CONCURRENT, then pQueueFamilyIndices must be a valid pointer to an array of queueFamilyIndexCount uint32_t values

Valid Usage (Implicit)

See Also

VK_EXT_image_drm_format_modifier, SharingMode, StructureType

Constructors

PhysicalDeviceImageDrmFormatModifierInfoEXT 

Fields

Instances

Instances details
Show PhysicalDeviceImageDrmFormatModifierInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct PhysicalDeviceImageDrmFormatModifierInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct PhysicalDeviceImageDrmFormatModifierInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero PhysicalDeviceImageDrmFormatModifierInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data ImageDrmFormatModifierListCreateInfoEXT Source #

VkImageDrmFormatModifierListCreateInfoEXT - Specify that an image must be created with a DRM format modifier from the provided list

Valid Usage

Valid Usage (Implicit)

  • pDrmFormatModifiers must be a valid pointer to an array of drmFormatModifierCount uint64_t values
  • drmFormatModifierCount must be greater than 0

See Also

VK_EXT_image_drm_format_modifier, StructureType

Constructors

ImageDrmFormatModifierListCreateInfoEXT 

Fields

data ImageDrmFormatModifierExplicitCreateInfoEXT Source #

VkImageDrmFormatModifierExplicitCreateInfoEXT - Specify that an image be created with the provided DRM format modifier and explicit memory layout

Description

The ith member of pPlaneLayouts describes the layout of the image’s ith memory plane (that is, VK_IMAGE_ASPECT_MEMORY_PLANE_i_BIT_EXT). In each element of pPlaneLayouts, the implementation must ignore size. The implementation calculates the size of each plane, which the application can query with getImageSubresourceLayout.

When creating an image with ImageDrmFormatModifierExplicitCreateInfoEXT, it is the application’s responsibility to satisfy all valid usage requirements. However, the implementation must validate that the provided pPlaneLayouts, when combined with the provided drmFormatModifier and other creation parameters in ImageCreateInfo and its pNext chain, produce a valid image. (This validation is necessarily implementation-dependent and outside the scope of Vulkan, and therefore not described by valid usage requirements). If this validation fails, then createImage returns ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT.

Valid Usage

Valid Usage (Implicit)

  • If drmFormatModifierPlaneCount is not 0, pPlaneLayouts must be a valid pointer to an array of drmFormatModifierPlaneCount SubresourceLayout structures

See Also

VK_EXT_image_drm_format_modifier, StructureType, SubresourceLayout

Constructors

ImageDrmFormatModifierExplicitCreateInfoEXT 

Fields

Instances

Instances details
Show ImageDrmFormatModifierExplicitCreateInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct ImageDrmFormatModifierExplicitCreateInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct ImageDrmFormatModifierExplicitCreateInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero ImageDrmFormatModifierExplicitCreateInfoEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data ImageDrmFormatModifierPropertiesEXT Source #

VkImageDrmFormatModifierPropertiesEXT - Properties of an image’s Linux DRM format modifier

Description

If the image was created with ImageDrmFormatModifierListCreateInfoEXT, then the returned drmFormatModifier must belong to the list of modifiers provided at time of image creation in ImageDrmFormatModifierListCreateInfoEXT::pDrmFormatModifiers. If the image was created with ImageDrmFormatModifierExplicitCreateInfoEXT, then the returned drmFormatModifier must be the modifier provided at time of image creation in ImageDrmFormatModifierExplicitCreateInfoEXT::drmFormatModifier.

Valid Usage (Implicit)

See Also

VK_EXT_image_drm_format_modifier, StructureType, getImageDrmFormatModifierPropertiesEXT

Constructors

ImageDrmFormatModifierPropertiesEXT 

Fields

Instances

Instances details
Eq ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Show ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Storable ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero ImageDrmFormatModifierPropertiesEXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data DrmFormatModifierPropertiesList2EXT Source #

VkDrmFormatModifierPropertiesList2EXT - Structure specifying the list of DRM format modifiers supported for a format

Description

If pDrmFormatModifierProperties is NULL, the number of modifiers compatible with the queried format is returned in drmFormatModifierCount. Otherwise, the application must set drmFormatModifierCount to the length of the array pDrmFormatModifierProperties; the function will write at most drmFormatModifierCount elements to the array, and will return in drmFormatModifierCount the number of elements written.

Among the elements in array pDrmFormatModifierProperties, each returned drmFormatModifier must be unique.

Among the elements in array pDrmFormatModifierProperties, the bits reported in drmFormatModifierTilingFeatures must include the bits reported in the corresponding element of DrmFormatModifierPropertiesListEXT::pDrmFormatModifierProperties.

Valid Usage (Implicit)

See Also

VK_EXT_image_drm_format_modifier, VK_KHR_format_feature_flags2, DrmFormatModifierProperties2EXT, StructureType

Constructors

DrmFormatModifierPropertiesList2EXT 

Fields

Instances

Instances details
Eq DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Show DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Storable DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero DrmFormatModifierPropertiesList2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

data DrmFormatModifierProperties2EXT Source #

VkDrmFormatModifierProperties2EXT - Structure specifying properties of a format when combined with a DRM format modifier

See Also

VK_EXT_image_drm_format_modifier, VK_KHR_format_feature_flags2, DrmFormatModifierPropertiesList2EXT, FormatFeatureFlags2KHR

Constructors

DrmFormatModifierProperties2EXT 

Fields

Instances

Instances details
Eq DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Show DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Storable DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

FromCStruct DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

ToCStruct DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

Zero DrmFormatModifierProperties2EXT Source # 
Instance details

Defined in Vulkan.Extensions.VK_EXT_image_drm_format_modifier

type EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME = "VK_EXT_image_drm_format_modifier" 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