Vulkan.Core11.Promoted_From_VK_KHR_maintenance1

vkTrimCommandPool - Trim a command pool

Description

Trimming a command pool recycles unused memory from the command pool back to the system. Command buffers allocated from the pool are not affected by the command.

This command provides applications with some control over the internal memory allocations used by command pools.

Unused memory normally arises from command buffers that have been recorded and later reset, such that they are no longer using the memory. On reset, a command buffer can return memory to its command pool, but the only way to release memory from a command pool to the system requires calling resetCommandPool, which cannot be executed while any command buffers from that pool are still in use. Subsequent recording operations into command buffers will reuse this memory but since total memory requirements fluctuate over time, unused memory can accumulate.

In this situation, trimming a command pool may be useful to return unused memory back to the system, returning the total outstanding memory allocated by the pool back to a more “average” value.

Implementations utilize many internal allocation strategies that make it impossible to guarantee that all unused memory is released back to the system. For instance, an implementation of a command pool may involve allocating memory in bulk from the system and sub-allocating from that memory. In such an implementation any live command buffer that holds a reference to a bulk allocation would prevent that allocation from being freed, even if only a small proportion of the bulk allocation is in use.

In most cases trimming will result in a reduction in allocated but unused memory, but it does not guarantee the “ideal” behavior.

Trimming may be an expensive operation, and should not be called frequently. Trimming should be treated as a way to relieve memory pressure after application-known points when there exists enough unused memory that the cost of trimming is “worth” it.

Valid Usage (Implicit)

• device must be a valid Device handle

• commandPool must be a valid CommandPool handle

• flags must be 0

• commandPool must have been created, allocated, or retrieved from device

Host Synchronization

• Host access to commandPool must be externally synchronized

See Also

VK_KHR_maintenance1, VK_VERSION_1_1, CommandPool, CommandPoolTrimFlags, Device

VkCommandPoolTrimFlags - Reserved for future use

Description

CommandPoolTrimFlags is a bitmask type for setting a mask, but is currently reserved for future use.

See Also

VK_KHR_maintenance1, VK_VERSION_1_1, Flags, trimCommandPool, trimCommandPool

VkResult - Vulkan command return codes

Description

• SUCCESS Command successfully completed

• NOT_READY A fence or query has not yet completed

• TIMEOUT A wait operation has not completed in the specified time

• EVENT_SET An event is signaled

• EVENT_RESET An event is unsignaled

• INCOMPLETE A return array was too small for the result

• SUBOPTIMAL_KHR A swapchain no longer matches the surface properties exactly, but can still be used to present to the surface successfully.

• THREAD_IDLE_KHR A deferred operation is not complete but there is currently no work for this thread to do at the time of this call.

• THREAD_DONE_KHR A deferred operation is not complete but there is no work remaining to assign to additional threads.

• OPERATION_DEFERRED_KHR A deferred operation was requested and at least some of the work was deferred.

• OPERATION_NOT_DEFERRED_KHR A deferred operation was requested and no operations were deferred.

• PIPELINE_COMPILE_REQUIRED A requested pipeline creation would have required compilation, but the application requested compilation to not be performed.

• PIPELINE_BINARY_MISSING_KHR The application attempted to create a pipeline binary by querying an internal cache, but the internal cache entry did not exist.

• INCOMPATIBLE_SHADER_BINARY_EXT The provided binary shader code is not compatible with this device.

  In the initial version of the VK_EXT_shader_object extension, this return code was named ERROR_INCOMPATIBLE_SHADER_BINARY_EXT and improperly described as an error code. The name has been changed, but the old name is retained as an alias for compatibility with old code.

• ERROR_OUT_OF_HOST_MEMORY A host memory allocation has failed.

• ERROR_OUT_OF_DEVICE_MEMORY A device memory allocation has failed.

• ERROR_INITIALIZATION_FAILED Initialization of an object could not be completed for implementation-specific reasons.

• ERROR_DEVICE_LOST The logical or physical device has been lost. See Lost Device

• ERROR_MEMORY_MAP_FAILED Mapping of a memory object has failed.

• ERROR_LAYER_NOT_PRESENT A requested layer is not present or could not be loaded.

• ERROR_EXTENSION_NOT_PRESENT A requested extension is not supported.

• ERROR_FEATURE_NOT_PRESENT A requested feature is not supported.

• ERROR_INCOMPATIBLE_DRIVER The requested version of Vulkan is not supported by the driver or is otherwise incompatible for implementation-specific reasons.

• ERROR_TOO_MANY_OBJECTS Too many objects of the type have already been created.

• ERROR_FORMAT_NOT_SUPPORTED A requested format is not supported on this device.

• ERROR_FRAGMENTED_POOL A pool allocation has failed due to fragmentation of the pool’s memory. This must only be returned if no attempt to allocate host or device memory was made to accommodate the new allocation. This should be returned in preference to ERROR_OUT_OF_POOL_MEMORY, but only if the implementation is certain that the pool allocation failure was due to fragmentation.

• ERROR_SURFACE_LOST_KHR A surface is no longer available.

• ERROR_NATIVE_WINDOW_IN_USE_KHR The requested window is already in use by Vulkan or another API in a manner which prevents it from being used again.

• ERROR_OUT_OF_DATE_KHR A surface has changed in such a way that it is no longer compatible with the swapchain, and further presentation requests using the swapchain will fail. Applications must query the new surface properties and recreate their swapchain if they wish to continue presenting to the surface.

• ERROR_INCOMPATIBLE_DISPLAY_KHR The display used by a swapchain does not use the same presentable image layout, or is incompatible in a way that prevents sharing an image.

• ERROR_INVALID_SHADER_NV One or more shaders failed to compile or link. More details are reported back to the application via VK_EXT_debug_report if enabled.

• ERROR_OUT_OF_POOL_MEMORY A pool memory allocation has failed. This must only be returned if no attempt to allocate host or device memory was made to accommodate the new allocation. If the failure was definitely due to fragmentation of the pool, ERROR_FRAGMENTED_POOL should be returned instead.

• ERROR_INVALID_EXTERNAL_HANDLE An external handle is not a valid handle of the specified type.

• ERROR_FRAGMENTATION A descriptor pool creation has failed due to fragmentation.

• ERROR_INVALID_DEVICE_ADDRESS_EXT A buffer creation failed because the requested address is not available.

• ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS A buffer creation or memory allocation failed because the requested address is not available. A shader group handle assignment failed because the requested shader group handle information is no longer valid.

• ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT An operation on a swapchain created with FULL_SCREEN_EXCLUSIVE_APPLICATION_CONTROLLED_EXT failed as it did not have exclusive full-screen access. This may occur due to implementation-dependent reasons, outside of the application’s control.

• ERROR_PRESENT_TIMING_QUEUE_FULL_EXT A present operation on a swapchain created with SWAPCHAIN_CREATE_PRESENT_TIMING_BIT_EXT failed due to insufficient space in the swapchain’s internal results queue to hold requested present timing data.

• ERROR_VALIDATION_FAILED A command failed because invalid usage was detected by the implementation or a validation layer. This may result in the command not being dispatched to the ICD.

• ERROR_COMPRESSION_EXHAUSTED_EXT An image creation failed because internal resources required for compression are exhausted. This must only be returned when fixed-rate compression is requested.

• VK_ERROR_IMAGE_USAGE_NOT_SUPPORTED_KHR The requested ImageUsageFlags are not supported.

• VK_ERROR_VIDEO_PICTURE_LAYOUT_NOT_SUPPORTED_KHR The requested video picture layout is not supported.

• VK_ERROR_VIDEO_PROFILE_OPERATION_NOT_SUPPORTED_KHR A video profile operation specified via VkVideoProfileInfoKHR::videoCodecOperation is not supported.

• VK_ERROR_VIDEO_PROFILE_FORMAT_NOT_SUPPORTED_KHR Format parameters in a requested VkVideoProfileInfoKHR chain are not supported.

• VK_ERROR_VIDEO_PROFILE_CODEC_NOT_SUPPORTED_KHR Codec-specific parameters in a requested VkVideoProfileInfoKHR chain are not supported.

• VK_ERROR_VIDEO_STD_VERSION_NOT_SUPPORTED_KHR The specified video Std header version is not supported.

• VK_ERROR_INVALID_VIDEO_STD_PARAMETERS_KHR The specified Video Std parameters do not adhere to the syntactic or semantic requirements of the used video compression standard, or values derived from parameters according to the rules defined by the used video compression standard do not adhere to the capabilities of the video compression standard or the implementation.

• ERROR_NOT_PERMITTED The driver implementation has denied a request to acquire a priority above the default priority (QUEUE_GLOBAL_PRIORITY_MEDIUM_EXT) because the application does not have sufficient privileges.

• ERROR_NOT_ENOUGH_SPACE_KHR The application did not provide enough space to return all the required data.

• ERROR_UNKNOWN An unknown error has occurred; either the application has provided invalid input, or an implementation failure has occurred.

If a command returns a runtime error, unless otherwise specified any output parameters will have undefined contents, except that if the output parameter is a structure with sType and pNext fields, those fields will be unmodified. Any structures chained from pNext will also have undefined contents, except that sType and pNext will be unmodified.

VK_ERROR_OUT_OF_*_MEMORY errors do not modify any currently existing Vulkan objects. Objects that have already been successfully created can still be used by the application.

As a general rule, Free, Release, and Reset commands do not return ERROR_OUT_OF_HOST_MEMORY, while any other command with a return code may return it. Any exceptions from this rule are described for those commands.

ERROR_UNKNOWN will be returned by an implementation when an unexpected error occurs that cannot be attributed to valid behavior of the application and implementation. Under these conditions, it may be returned from any command returning a Result.

ERROR_UNKNOWN is not expected to ever be returned if the application behavior is valid, and if the implementation is bug-free. If ERROR_UNKNOWN is returned, the application should be checked against the latest validation layers to verify correct behavior as much as possible. If no issues are identified it could be an implementation issue, and the implementor should be contacted for support.

Any command returning a Result may return ERROR_VALIDATION_FAILED if a violation of valid usage is detected.

Performance-critical commands generally do not have return codes. If a runtime error occurs in such commands, the implementation will defer reporting the error until a specified point. For commands that record into command buffers (vkCmd*) runtime errors are reported by endCommandBuffer.

See Also

VK_VERSION_1_0, BindMemoryStatus, PresentInfoKHR

VkImageCreateFlagBits - Bitmask specifying additional parameters of an image

Description

• IMAGE_CREATE_SPARSE_BINDING_BIT specifies that the image will be backed using sparse memory binding.

• IMAGE_CREATE_SPARSE_RESIDENCY_BIT specifies that the image can be partially backed using sparse memory binding. Images created with this flag must also be created with the IMAGE_CREATE_SPARSE_BINDING_BIT flag.

• IMAGE_CREATE_SPARSE_ALIASED_BIT specifies that the image will be backed using sparse memory binding with memory ranges that might also simultaneously be backing another image (or another portion of the same image). Images created with this flag must also be created with the IMAGE_CREATE_SPARSE_BINDING_BIT flag.

• IMAGE_CREATE_MUTABLE_FORMAT_BIT specifies that the image can be used to create a ImageView with a different format from the image. For multi-planar formats, IMAGE_CREATE_MUTABLE_FORMAT_BIT specifies that a ImageView can be created of a plane of the image.

• IMAGE_CREATE_CUBE_COMPATIBLE_BIT specifies that the image can be used to create a ImageView of type IMAGE_VIEW_TYPE_CUBE or IMAGE_VIEW_TYPE_CUBE_ARRAY.

• IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT specifies that the image can be used to create a ImageView of type IMAGE_VIEW_TYPE_2D or IMAGE_VIEW_TYPE_2D_ARRAY.

• IMAGE_CREATE_2D_VIEW_COMPATIBLE_BIT_EXT specifies that the image can be used to create a ImageView of type IMAGE_VIEW_TYPE_2D.

• IMAGE_CREATE_PROTECTED_BIT specifies that the image is a protected image.

• IMAGE_CREATE_SPLIT_INSTANCE_BIND_REGIONS_BIT specifies that the image can be used with a non-zero value of the splitInstanceBindRegionCount member of a BindImageMemoryDeviceGroupInfo structure passed into bindImageMemory2. This flag also has the effect of making the image use the standard sparse image block dimensions.

• IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT specifies that the image having a compressed format can be used to create a ImageView with an uncompressed format where each texel in the image view corresponds to a compressed texel block of the image.

• IMAGE_CREATE_EXTENDED_USAGE_BIT specifies that the image can be created with usage flags that are not supported for the format the image is created with but are supported for at least one format a ImageView created from the image can have.

• IMAGE_CREATE_DISJOINT_BIT specifies that an image with a multi-planar format must have each plane separately bound to memory, rather than having a single memory binding for the whole image; the presence of this bit distinguishes a disjoint image from an image without this bit set.

• IMAGE_CREATE_ALIAS_BIT specifies that two images created with the same creation parameters and aliased to the same memory can interpret the contents of the memory consistently with each other, subject to the rules described in the Memory Aliasing section. This flag further specifies that each plane of a disjoint image can share an in-memory non-linear representation with single-plane images, and that a single-plane image can share an in-memory non-linear representation with a plane of a multi-planar disjoint image, according to the rules in https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#formats-compatible-planes. If the pNext chain includes a ExternalMemoryImageCreateInfo or ExternalMemoryImageCreateInfoNV structure whose handleTypes member is not 0, it is as if IMAGE_CREATE_ALIAS_BIT is set.

• IMAGE_CREATE_SAMPLE_LOCATIONS_COMPATIBLE_DEPTH_BIT_EXT specifies that an image with a depth or depth/stencil format can be used with custom sample locations when used as a depth/stencil attachment.

• IMAGE_CREATE_CORNER_SAMPLED_BIT_NV specifies that the image is a corner-sampled image.

• IMAGE_CREATE_SUBSAMPLED_BIT_EXT specifies that an image can be in a subsampled format which may be more optimal when written as an attachment by a render pass that has a fragment density map attachment. Accessing a subsampled image has additional considerations:

  • Image data read as an image sampler will have undefined values if the sampler was not created with flags containing SAMPLER_CREATE_SUBSAMPLED_BIT_EXT or was not sampled through a combined embedded sampler and image mapping if using descriptor heaps, or the use of a combined image sampler with an immutable sampler in DescriptorSetLayoutBinding.

  • Image data read with an input attachment will have undefined values if the contents were not written as an attachment in an earlier subpass of the same render pass.

  • Image data read as an image sampler in the fragment shader will be additionally be read by the device during PIPELINE_STAGE_VERTEX_SHADER_BIT if ::subsampledCoarseReconstructionEarlyAccess is TRUE and the sampler was created with flags containing SAMPLER_CREATE_SUBSAMPLED_COARSE_RECONSTRUCTION_BIT_EXT.

  • Image data read with load operations are resampled to the fragment density of the render pass if ::subsampledLoads is TRUE. Otherwise, values of image data are undefined.

  • Image contents outside of the render area take on undefined values if the image is stored as a render pass attachment.

• IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT specifies that an image can be used in a render pass with non-zero fragment density map offsets. In a render pass with non-zero offsets, fragment density map attachments, input attachments, color attachments, depth/stencil attachment, resolve attachments, and preserve attachments must be created with IMAGE_CREATE_FRAGMENT_DENSITY_MAP_OFFSET_BIT_EXT.

• IMAGE_CREATE_DESCRIPTOR_BUFFER_CAPTURE_REPLAY_BIT_EXT specifies that the image can be used with descriptor buffers when capturing and replaying (e.g. for trace capture and replay), see OpaqueCaptureDescriptorDataCreateInfoEXT for more detail.

• IMAGE_CREATE_MULTISAMPLED_RENDER_TO_SINGLE_SAMPLED_BIT_EXT specifies that an image can be used with multisampled rendering as a single-sampled framebuffer attachment

• IMAGE_CREATE_ALIAS_SINGLE_LAYER_DESCRIPTOR_BIT_KHR specifies that a single layer image view created from this image can be accessed with both Arrayed equal to 0 and Arrayed equal to 1 in a shader. If accessed with Arrayed equal to 1 in a shader, and ImageViewCreateInfo::viewType is IMAGE_VIEW_TYPE_1D or IMAGE_VIEW_TYPE_2D, the image is treated as having an array size of 1, and subresourceRange.baseArrayLayer is accessed. If accessed with Arrayed equal to 0 in a shader, and ImageViewCreateInfo::viewType is IMAGE_VIEW_TYPE_1D_ARRAY or IMAGE_VIEW_TYPE_2D_ARRAY, the descriptor is accessed as-if the view was created with IMAGE_VIEW_TYPE_1D or IMAGE_VIEW_TYPE_2D respectively. Cube map view aliasing is not included by this flag bit. Also, image views created with a multi-planar format can not alias like this.

• VK_IMAGE_CREATE_VIDEO_PROFILE_INDEPENDENT_BIT_KHR specifies that the image can be used in video coding operations without having to specify at image creation time the set of video profiles the image will be used with, except for images used only as DPB pictures, as long as the image is otherwise compatible with the video profile in question.

  This enables exchanging video picture data without additional copies or conversions when used as:

  • Decode output pictures, regardless of the video profile used to produce them.

  • Encode input pictures, regardless of the video profile used to consume them.

  This includes images created with both VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR and VK_IMAGE_USAGE_VIDEO_DECODE_DPB_BIT_KHR, which is necessary to use the same video picture as the reconstructed picture and decode output picture in a video decode operation on implementations supporting VK_VIDEO_DECODE_CAPABILITY_DPB_AND_OUTPUT_COINCIDE_BIT_KHR.

  However, images with only DPB usage remain tied to the video profiles the image was created with, as the data layout of such DPB-only images may be implementation- and codec-dependent.

  If an application would like to share or reuse the device memory backing such images (e.g. for the purposes of temporal aliasing), then it should create separate image objects for each video profile and bind them to the same underlying device memory range, similar to how memory resources can be shared across separate video sessions or any other memory-backed resource.

See Sparse Resource Features and Sparse Physical Device Features for more details.

See Also

VK_VERSION_1_0, ImageCreateFlags

VkFormatFeatureFlagBits - Bitmask specifying features supported by a buffer

Description

These values all have the same meaning as the equivalently named values for FormatFeatureFlags2 and may be set in linearTilingFeatures, optimalTilingFeatures, and DrmFormatModifierPropertiesEXT::drmFormatModifierTilingFeatures, specifying that the features are supported by images or image views or sampler Y′CBCR conversion objects created with the queried getPhysicalDeviceFormatProperties::format:

• FORMAT_FEATURE_SAMPLED_IMAGE_BIT specifies that an image view can be sampled from.

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

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

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

• FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT specifies that an image view can be used as a framebuffer color attachment that supports blending.

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

• FORMAT_FEATURE_BLIT_SRC_BIT specifies that an image can be used as srcImage for the cmdBlitImage2 and cmdBlitImage commands.

• FORMAT_FEATURE_BLIT_DST_BIT specifies that an image can be used as dstImage for the cmdBlitImage2 and cmdBlitImage commands.

• FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT specifies that if FORMAT_FEATURE_SAMPLED_IMAGE_BIT 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_BLIT_SRC_BIT is also set, an image can be used as the srcImage to cmdBlitImage2 and cmdBlitImage with a filter of FILTER_LINEAR. This bit must only be exposed for formats that also support the FORMAT_FEATURE_SAMPLED_IMAGE_BIT or FORMAT_FEATURE_BLIT_SRC_BIT.

  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, and that linear filtering of the depth aspect is supported whether depth compare is enabled in the sampler or not. 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_TRANSFER_SRC_BIT specifies that an image can be used as a source image for copy commands. If the application apiVersion is Vulkan 1.0 and VK_KHR_maintenance1 is not supported, FORMAT_FEATURE_TRANSFER_SRC_BIT is implied to be set when the format feature flag is not 0.

• FORMAT_FEATURE_TRANSFER_DST_BIT specifies that an image can be used as a destination image for copy commands and clear commands. If the application apiVersion is Vulkan 1.0 and VK_KHR_maintenance1 is not supported, FORMAT_FEATURE_TRANSFER_DST_BIT is implied to be set when the format feature flag is not 0.

• FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT 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_SAMPLED_IMAGE_BIT.

• FORMAT_FEATURE_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_SAMPLED_IMAGE_BIT. If the format being queried is a depth/stencil format, this only specifies that the depth aspect is cubic filterable.

• FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT 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_MIDPOINT_CHROMA_SAMPLES_BIT.

• FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT 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_COSITED_CHROMA_SAMPLES_BIT nor FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT is set, the application must not define a sampler Y′CBCR conversion using this format as a source.

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

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

• FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT specifies that reconstruction is explicit, as described in https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#textures-chroma-reconstruction. If this bit is not present, reconstruction is implicit by default.

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

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

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

• FORMAT_FEATURE_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 a numeric format other than UINT, or set it as a buffer feature.

• VK_FORMAT_FEATURE_VIDEO_DECODE_OUTPUT_BIT_KHR specifies that an image view with this format can be used as a decode output picture in video decode operations.

• VK_FORMAT_FEATURE_VIDEO_DECODE_DPB_BIT_KHR specifies that an image view with this format can be used as an output reconstructed picture or an input reference picture in video decode operations.

• VK_FORMAT_FEATURE_VIDEO_ENCODE_INPUT_BIT_KHR specifies that an image view with this format can be used as an encode input picture in video encode operations.

• VK_FORMAT_FEATURE_VIDEO_ENCODE_DPB_BIT_KHR specifies that an image view with this format can be used as an output reconstructed picture or an input reference picture in video encode operations.

  Specific video profiles may have additional restrictions on the format and other image creation parameters corresponding to image views used by video coding operations that can be enumerated using the vkGetPhysicalDeviceVideoFormatPropertiesKHR command.

The following bits may be set in bufferFeatures, specifying that the features are supported by buffers or buffer views created with the queried getPhysicalDeviceFormatProperties::format:

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

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

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

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

• FORMAT_FEATURE_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.

FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT and FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT are only intended to be advertised for single-component formats, since SPIR-V atomic operations require a scalar type.

See Also

VK_VERSION_1_0, FormatFeatureFlags