Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
// Copyright (c) 2015-2019 Khronos Group. This work is licensed under a
// Creative Commons Attribution 4.0 International License; see
// http://creativecommons.org/licenses/by/4.0/
[[formats]]
= Formats
Supported buffer and image formats may: vary across implementations.
A minimum set of format features are guaranteed, but others must: be
explicitly queried before use to ensure they are supported by the
implementation.
The features for the set of formats (elink:VkFormat) supported by the
implementation are queried individually using the
flink:vkGetPhysicalDeviceFormatProperties command.
[[formats-definition]]
== Format Definition
[open,refpage='VkFormat',desc='Available image formats',type='enums']
--
The following image formats can: be passed to, and may: be returned from
Vulkan commands.
The memory required to store each format is discussed with that format, and
also summarized in the <<texel-block-size, Representation and Texel Block
Size>> section and the <<formats-compatibility, Compatible formats>> table.
2019-04-16 12:19:43 +00:00
include::{generated}/api/enums/VkFormat.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* ename:VK_FORMAT_UNDEFINED specifies that the format is not specified.
* ename:VK_FORMAT_R4G4_UNORM_PACK8 specifies a two-component, 8-bit packed
unsigned normalized format that has a 4-bit R component in bits 4..7,
and a 4-bit G component in bits 0..3.
* ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16 specifies a four-component, 16-bit
packed unsigned normalized format that has a 4-bit R component in bits
12..15, a 4-bit G component in bits 8..11, a 4-bit B component in bits
4..7, and a 4-bit A component in bits 0..3.
* ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16 specifies a four-component, 16-bit
packed unsigned normalized format that has a 4-bit B component in bits
12..15, a 4-bit G component in bits 8..11, a 4-bit R component in bits
4..7, and a 4-bit A component in bits 0..3.
* ename:VK_FORMAT_R5G6B5_UNORM_PACK16 specifies a three-component, 16-bit
packed unsigned normalized format that has a 5-bit R component in bits
11..15, a 6-bit G component in bits 5..10, and a 5-bit B component in
bits 0..4.
* ename:VK_FORMAT_B5G6R5_UNORM_PACK16 specifies a three-component, 16-bit
packed unsigned normalized format that has a 5-bit B component in bits
11..15, a 6-bit G component in bits 5..10, and a 5-bit R component in
bits 0..4.
* ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16 specifies a four-component, 16-bit
packed unsigned normalized format that has a 5-bit R component in bits
11..15, a 5-bit G component in bits 6..10, a 5-bit B component in bits
1..5, and a 1-bit A component in bit 0.
* ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16 specifies a four-component, 16-bit
packed unsigned normalized format that has a 5-bit B component in bits
11..15, a 5-bit G component in bits 6..10, a 5-bit R component in bits
1..5, and a 1-bit A component in bit 0.
* ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16 specifies a four-component, 16-bit
packed unsigned normalized format that has a 1-bit A component in bit
15, a 5-bit R component in bits 10..14, a 5-bit G component in bits
5..9, and a 5-bit B component in bits 0..4.
* ename:VK_FORMAT_R8_UNORM specifies a one-component, 8-bit unsigned
normalized format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_SNORM specifies a one-component, 8-bit signed
normalized format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_USCALED specifies a one-component, 8-bit unsigned
scaled integer format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_SSCALED specifies a one-component, 8-bit signed
scaled integer format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_UINT specifies a one-component, 8-bit unsigned
integer format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_SINT specifies a one-component, 8-bit signed integer
format that has a single 8-bit R component.
* ename:VK_FORMAT_R8_SRGB specifies a one-component, 8-bit unsigned
normalized format that has a single 8-bit R component stored with sRGB
nonlinear encoding.
* ename:VK_FORMAT_R8G8_UNORM specifies a two-component, 16-bit unsigned
normalized format that has an 8-bit R component in byte 0, and an 8-bit
G component in byte 1.
* ename:VK_FORMAT_R8G8_SNORM specifies a two-component, 16-bit signed
normalized format that has an 8-bit R component in byte 0, and an 8-bit
G component in byte 1.
* ename:VK_FORMAT_R8G8_USCALED specifies a two-component, 16-bit unsigned
scaled integer format that has an 8-bit R component in byte 0, and an
8-bit G component in byte 1.
* ename:VK_FORMAT_R8G8_SSCALED specifies a two-component, 16-bit signed
scaled integer format that has an 8-bit R component in byte 0, and an
8-bit G component in byte 1.
* ename:VK_FORMAT_R8G8_UINT specifies a two-component, 16-bit unsigned
integer format that has an 8-bit R component in byte 0, and an 8-bit G
component in byte 1.
* ename:VK_FORMAT_R8G8_SINT specifies a two-component, 16-bit signed
integer format that has an 8-bit R component in byte 0, and an 8-bit G
component in byte 1.
* ename:VK_FORMAT_R8G8_SRGB specifies a two-component, 16-bit unsigned
normalized format that has an 8-bit R component stored with sRGB
nonlinear encoding in byte 0, and an 8-bit G component stored with sRGB
nonlinear encoding in byte 1.
* ename:VK_FORMAT_R8G8B8_UNORM specifies a three-component, 24-bit
unsigned normalized format that has an 8-bit R component in byte 0, an
8-bit G component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_SNORM specifies a three-component, 24-bit signed
normalized format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_USCALED specifies a three-component, 24-bit
unsigned scaled format that has an 8-bit R component in byte 0, an 8-bit
G component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_SSCALED specifies a three-component, 24-bit
signed scaled format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_UINT specifies a three-component, 24-bit unsigned
integer format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_SINT specifies a three-component, 24-bit signed
integer format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, and an 8-bit B component in byte 2.
* ename:VK_FORMAT_R8G8B8_SRGB specifies a three-component, 24-bit unsigned
normalized format that has an 8-bit R component stored with sRGB
nonlinear encoding in byte 0, an 8-bit G component stored with sRGB
nonlinear encoding in byte 1, and an 8-bit B component stored with sRGB
nonlinear encoding in byte 2.
* ename:VK_FORMAT_B8G8R8_UNORM specifies a three-component, 24-bit
unsigned normalized format that has an 8-bit B component in byte 0, an
8-bit G component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_SNORM specifies a three-component, 24-bit signed
normalized format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_USCALED specifies a three-component, 24-bit
unsigned scaled format that has an 8-bit B component in byte 0, an 8-bit
G component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_SSCALED specifies a three-component, 24-bit
signed scaled format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_UINT specifies a three-component, 24-bit unsigned
integer format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_SINT specifies a three-component, 24-bit signed
integer format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, and an 8-bit R component in byte 2.
* ename:VK_FORMAT_B8G8R8_SRGB specifies a three-component, 24-bit unsigned
normalized format that has an 8-bit B component stored with sRGB
nonlinear encoding in byte 0, an 8-bit G component stored with sRGB
nonlinear encoding in byte 1, and an 8-bit R component stored with sRGB
nonlinear encoding in byte 2.
* ename:VK_FORMAT_R8G8B8A8_UNORM specifies a four-component, 32-bit
unsigned normalized format that has an 8-bit R component in byte 0, an
8-bit G component in byte 1, an 8-bit B component in byte 2, and an
8-bit A component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_SNORM specifies a four-component, 32-bit signed
normalized format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, an 8-bit B component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_USCALED specifies a four-component, 32-bit
unsigned scaled format that has an 8-bit R component in byte 0, an 8-bit
G component in byte 1, an 8-bit B component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_SSCALED specifies a four-component, 32-bit
signed scaled format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, an 8-bit B component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_UINT specifies a four-component, 32-bit
unsigned integer format that has an 8-bit R component in byte 0, an
8-bit G component in byte 1, an 8-bit B component in byte 2, and an
8-bit A component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_SINT specifies a four-component, 32-bit signed
integer format that has an 8-bit R component in byte 0, an 8-bit G
component in byte 1, an 8-bit B component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_R8G8B8A8_SRGB specifies a four-component, 32-bit
unsigned normalized format that has an 8-bit R component stored with
sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB
nonlinear encoding in byte 1, an 8-bit B component stored with sRGB
nonlinear encoding in byte 2, and an 8-bit A component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_UNORM specifies a four-component, 32-bit
unsigned normalized format that has an 8-bit B component in byte 0, an
8-bit G component in byte 1, an 8-bit R component in byte 2, and an
8-bit A component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_SNORM specifies a four-component, 32-bit signed
normalized format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, an 8-bit R component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_USCALED specifies a four-component, 32-bit
unsigned scaled format that has an 8-bit B component in byte 0, an 8-bit
G component in byte 1, an 8-bit R component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_SSCALED specifies a four-component, 32-bit
signed scaled format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, an 8-bit R component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_UINT specifies a four-component, 32-bit
unsigned integer format that has an 8-bit B component in byte 0, an
8-bit G component in byte 1, an 8-bit R component in byte 2, and an
8-bit A component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_SINT specifies a four-component, 32-bit signed
integer format that has an 8-bit B component in byte 0, an 8-bit G
component in byte 1, an 8-bit R component in byte 2, and an 8-bit A
component in byte 3.
* ename:VK_FORMAT_B8G8R8A8_SRGB specifies a four-component, 32-bit
unsigned normalized format that has an 8-bit B component stored with
sRGB nonlinear encoding in byte 0, an 8-bit G component stored with sRGB
nonlinear encoding in byte 1, an 8-bit R component stored with sRGB
nonlinear encoding in byte 2, and an 8-bit A component in byte 3.
* ename:VK_FORMAT_A8B8G8R8_UNORM_PACK32 specifies a four-component, 32-bit
packed unsigned normalized format that has an 8-bit A component in bits
24..31, an 8-bit B component in bits 16..23, an 8-bit G component in
bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_SNORM_PACK32 specifies a four-component, 32-bit
packed signed normalized format that has an 8-bit A component in bits
24..31, an 8-bit B component in bits 16..23, an 8-bit G component in
bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_USCALED_PACK32 specifies a four-component,
32-bit packed unsigned scaled integer format that has an 8-bit A
component in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit
G component in bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_SSCALED_PACK32 specifies a four-component,
32-bit packed signed scaled integer format that has an 8-bit A component
in bits 24..31, an 8-bit B component in bits 16..23, an 8-bit G
component in bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_UINT_PACK32 specifies a four-component, 32-bit
packed unsigned integer format that has an 8-bit A component in bits
24..31, an 8-bit B component in bits 16..23, an 8-bit G component in
bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_SINT_PACK32 specifies a four-component, 32-bit
packed signed integer format that has an 8-bit A component in bits
24..31, an 8-bit B component in bits 16..23, an 8-bit G component in
bits 8..15, and an 8-bit R component in bits 0..7.
* ename:VK_FORMAT_A8B8G8R8_SRGB_PACK32 specifies a four-component, 32-bit
packed unsigned normalized format that has an 8-bit A component in bits
24..31, an 8-bit B component stored with sRGB nonlinear encoding in bits
16..23, an 8-bit G component stored with sRGB nonlinear encoding in bits
8..15, and an 8-bit R component stored with sRGB nonlinear encoding in
bits 0..7.
* ename:VK_FORMAT_A2R10G10B10_UNORM_PACK32 specifies a four-component,
32-bit packed unsigned normalized format that has a 2-bit A component in
bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2R10G10B10_SNORM_PACK32 specifies a four-component,
32-bit packed signed normalized format that has a 2-bit A component in
bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2R10G10B10_USCALED_PACK32 specifies a four-component,
32-bit packed unsigned scaled integer format that has a 2-bit A
component in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit
G component in bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2R10G10B10_SSCALED_PACK32 specifies a four-component,
32-bit packed signed scaled integer format that has a 2-bit A component
in bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G
component in bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2R10G10B10_UINT_PACK32 specifies a four-component,
32-bit packed unsigned integer format that has a 2-bit A component in
bits 30..31, a 10-bit R component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2R10G10B10_SINT_PACK32 specifies a four-component,
32-bit packed signed integer format that has a 2-bit A component in bits
30..31, a 10-bit R component in bits 20..29, a 10-bit G component in
bits 10..19, and a 10-bit B component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_UNORM_PACK32 specifies a four-component,
32-bit packed unsigned normalized format that has a 2-bit A component in
bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_SNORM_PACK32 specifies a four-component,
32-bit packed signed normalized format that has a 2-bit A component in
bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_USCALED_PACK32 specifies a four-component,
32-bit packed unsigned scaled integer format that has a 2-bit A
component in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit
G component in bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_SSCALED_PACK32 specifies a four-component,
32-bit packed signed scaled integer format that has a 2-bit A component
in bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G
component in bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_UINT_PACK32 specifies a four-component,
32-bit packed unsigned integer format that has a 2-bit A component in
bits 30..31, a 10-bit B component in bits 20..29, a 10-bit G component
in bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_A2B10G10R10_SINT_PACK32 specifies a four-component,
32-bit packed signed integer format that has a 2-bit A component in bits
30..31, a 10-bit B component in bits 20..29, a 10-bit G component in
bits 10..19, and a 10-bit R component in bits 0..9.
* ename:VK_FORMAT_R16_UNORM specifies a one-component, 16-bit unsigned
normalized format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_SNORM specifies a one-component, 16-bit signed
normalized format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_USCALED specifies a one-component, 16-bit unsigned
scaled integer format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_SSCALED specifies a one-component, 16-bit signed
scaled integer format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_UINT specifies a one-component, 16-bit unsigned
integer format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_SINT specifies a one-component, 16-bit signed
integer format that has a single 16-bit R component.
* ename:VK_FORMAT_R16_SFLOAT specifies a one-component, 16-bit signed
floating-point format that has a single 16-bit R component.
* ename:VK_FORMAT_R16G16_UNORM specifies a two-component, 32-bit unsigned
normalized format that has a 16-bit R component in bytes 0..1, and a
16-bit G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_SNORM specifies a two-component, 32-bit signed
normalized format that has a 16-bit R component in bytes 0..1, and a
16-bit G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_USCALED specifies a two-component, 32-bit
unsigned scaled integer format that has a 16-bit R component in bytes
0..1, and a 16-bit G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_SSCALED specifies a two-component, 32-bit signed
scaled integer format that has a 16-bit R component in bytes 0..1, and a
16-bit G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_UINT specifies a two-component, 32-bit unsigned
integer format that has a 16-bit R component in bytes 0..1, and a 16-bit
G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_SINT specifies a two-component, 32-bit signed
integer format that has a 16-bit R component in bytes 0..1, and a 16-bit
G component in bytes 2..3.
* ename:VK_FORMAT_R16G16_SFLOAT specifies a two-component, 32-bit signed
floating-point format that has a 16-bit R component in bytes 0..1, and a
16-bit G component in bytes 2..3.
* ename:VK_FORMAT_R16G16B16_UNORM specifies a three-component, 48-bit
unsigned normalized format that has a 16-bit R component in bytes 0..1,
a 16-bit G component in bytes 2..3, and a 16-bit B component in bytes
4..5.
* ename:VK_FORMAT_R16G16B16_SNORM specifies a three-component, 48-bit
signed normalized format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, and a 16-bit B component in bytes
4..5.
* ename:VK_FORMAT_R16G16B16_USCALED specifies a three-component, 48-bit
unsigned scaled integer format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in
bytes 4..5.
* ename:VK_FORMAT_R16G16B16_SSCALED specifies a three-component, 48-bit
signed scaled integer format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in
bytes 4..5.
* ename:VK_FORMAT_R16G16B16_UINT specifies a three-component, 48-bit
unsigned integer format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, and a 16-bit B component in bytes
4..5.
* ename:VK_FORMAT_R16G16B16_SINT specifies a three-component, 48-bit
signed integer format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, and a 16-bit B component in bytes
4..5.
* ename:VK_FORMAT_R16G16B16_SFLOAT specifies a three-component, 48-bit
signed floating-point format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, and a 16-bit B component in
bytes 4..5.
* ename:VK_FORMAT_R16G16B16A16_UNORM specifies a four-component, 64-bit
unsigned normalized format that has a 16-bit R component in bytes 0..1,
a 16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5,
and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_SNORM specifies a four-component, 64-bit
signed normalized format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5,
and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_USCALED specifies a four-component, 64-bit
unsigned scaled integer format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes
4..5, and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_SSCALED specifies a four-component, 64-bit
signed scaled integer format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes
4..5, and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_UINT specifies a four-component, 64-bit
unsigned integer format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5,
and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_SINT specifies a four-component, 64-bit
signed integer format that has a 16-bit R component in bytes 0..1, a
16-bit G component in bytes 2..3, a 16-bit B component in bytes 4..5,
and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R16G16B16A16_SFLOAT specifies a four-component, 64-bit
signed floating-point format that has a 16-bit R component in bytes
0..1, a 16-bit G component in bytes 2..3, a 16-bit B component in bytes
4..5, and a 16-bit A component in bytes 6..7.
* ename:VK_FORMAT_R32_UINT specifies a one-component, 32-bit unsigned
integer format that has a single 32-bit R component.
* ename:VK_FORMAT_R32_SINT specifies a one-component, 32-bit signed
integer format that has a single 32-bit R component.
* ename:VK_FORMAT_R32_SFLOAT specifies a one-component, 32-bit signed
floating-point format that has a single 32-bit R component.
* ename:VK_FORMAT_R32G32_UINT specifies a two-component, 64-bit unsigned
integer format that has a 32-bit R component in bytes 0..3, and a 32-bit
G component in bytes 4..7.
* ename:VK_FORMAT_R32G32_SINT specifies a two-component, 64-bit signed
integer format that has a 32-bit R component in bytes 0..3, and a 32-bit
G component in bytes 4..7.
* ename:VK_FORMAT_R32G32_SFLOAT specifies a two-component, 64-bit signed
floating-point format that has a 32-bit R component in bytes 0..3, and a
32-bit G component in bytes 4..7.
* ename:VK_FORMAT_R32G32B32_UINT specifies a three-component, 96-bit
unsigned integer format that has a 32-bit R component in bytes 0..3, a
32-bit G component in bytes 4..7, and a 32-bit B component in bytes
8..11.
* ename:VK_FORMAT_R32G32B32_SINT specifies a three-component, 96-bit
signed integer format that has a 32-bit R component in bytes 0..3, a
32-bit G component in bytes 4..7, and a 32-bit B component in bytes
8..11.
* ename:VK_FORMAT_R32G32B32_SFLOAT specifies a three-component, 96-bit
signed floating-point format that has a 32-bit R component in bytes
0..3, a 32-bit G component in bytes 4..7, and a 32-bit B component in
bytes 8..11.
* ename:VK_FORMAT_R32G32B32A32_UINT specifies a four-component, 128-bit
unsigned integer format that has a 32-bit R component in bytes 0..3, a
32-bit G component in bytes 4..7, a 32-bit B component in bytes 8..11,
and a 32-bit A component in bytes 12..15.
* ename:VK_FORMAT_R32G32B32A32_SINT specifies a four-component, 128-bit
signed integer format that has a 32-bit R component in bytes 0..3, a
32-bit G component in bytes 4..7, a 32-bit B component in bytes 8..11,
and a 32-bit A component in bytes 12..15.
* ename:VK_FORMAT_R32G32B32A32_SFLOAT specifies a four-component, 128-bit
signed floating-point format that has a 32-bit R component in bytes
0..3, a 32-bit G component in bytes 4..7, a 32-bit B component in bytes
8..11, and a 32-bit A component in bytes 12..15.
* ename:VK_FORMAT_R64_UINT specifies a one-component, 64-bit unsigned
integer format that has a single 64-bit R component.
* ename:VK_FORMAT_R64_SINT specifies a one-component, 64-bit signed
integer format that has a single 64-bit R component.
* ename:VK_FORMAT_R64_SFLOAT specifies a one-component, 64-bit signed
floating-point format that has a single 64-bit R component.
* ename:VK_FORMAT_R64G64_UINT specifies a two-component, 128-bit unsigned
integer format that has a 64-bit R component in bytes 0..7, and a 64-bit
G component in bytes 8..15.
* ename:VK_FORMAT_R64G64_SINT specifies a two-component, 128-bit signed
integer format that has a 64-bit R component in bytes 0..7, and a 64-bit
G component in bytes 8..15.
* ename:VK_FORMAT_R64G64_SFLOAT specifies a two-component, 128-bit signed
floating-point format that has a 64-bit R component in bytes 0..7, and a
64-bit G component in bytes 8..15.
* ename:VK_FORMAT_R64G64B64_UINT specifies a three-component, 192-bit
unsigned integer format that has a 64-bit R component in bytes 0..7, a
64-bit G component in bytes 8..15, and a 64-bit B component in bytes
16..23.
* ename:VK_FORMAT_R64G64B64_SINT specifies a three-component, 192-bit
signed integer format that has a 64-bit R component in bytes 0..7, a
64-bit G component in bytes 8..15, and a 64-bit B component in bytes
16..23.
* ename:VK_FORMAT_R64G64B64_SFLOAT specifies a three-component, 192-bit
signed floating-point format that has a 64-bit R component in bytes
0..7, a 64-bit G component in bytes 8..15, and a 64-bit B component in
bytes 16..23.
* ename:VK_FORMAT_R64G64B64A64_UINT specifies a four-component, 256-bit
unsigned integer format that has a 64-bit R component in bytes 0..7, a
64-bit G component in bytes 8..15, a 64-bit B component in bytes 16..23,
and a 64-bit A component in bytes 24..31.
* ename:VK_FORMAT_R64G64B64A64_SINT specifies a four-component, 256-bit
signed integer format that has a 64-bit R component in bytes 0..7, a
64-bit G component in bytes 8..15, a 64-bit B component in bytes 16..23,
and a 64-bit A component in bytes 24..31.
* ename:VK_FORMAT_R64G64B64A64_SFLOAT specifies a four-component, 256-bit
signed floating-point format that has a 64-bit R component in bytes
0..7, a 64-bit G component in bytes 8..15, a 64-bit B component in bytes
16..23, and a 64-bit A component in bytes 24..31.
* ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32 specifies a three-component,
32-bit packed unsigned floating-point format that has a 10-bit B
component in bits 22..31, an 11-bit G component in bits 11..21, an
11-bit R component in bits 0..10.
See <<fundamentals-fp10>> and <<fundamentals-fp11>>.
* ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 specifies a three-component,
32-bit packed unsigned floating-point format that has a 5-bit shared
exponent in bits 27..31, a 9-bit B component mantissa in bits 18..26, a
9-bit G component mantissa in bits 9..17, and a 9-bit R component
mantissa in bits 0..8.
* ename:VK_FORMAT_D16_UNORM specifies a one-component, 16-bit unsigned
normalized format that has a single 16-bit depth component.
* ename:VK_FORMAT_X8_D24_UNORM_PACK32 specifies a two-component, 32-bit
format that has 24 unsigned normalized bits in the depth component and,
optionally:, 8 bits that are unused.
* ename:VK_FORMAT_D32_SFLOAT specifies a one-component, 32-bit signed
floating-point format that has 32-bits in the depth component.
* ename:VK_FORMAT_S8_UINT specifies a one-component, 8-bit unsigned
integer format that has 8-bits in the stencil component.
* ename:VK_FORMAT_D16_UNORM_S8_UINT specifies a two-component, 24-bit
format that has 16 unsigned normalized bits in the depth component and 8
unsigned integer bits in the stencil component.
* ename:VK_FORMAT_D24_UNORM_S8_UINT specifies a two-component, 32-bit
packed format that has 8 unsigned integer bits in the stencil component,
and 24 unsigned normalized bits in the depth component.
* ename:VK_FORMAT_D32_SFLOAT_S8_UINT specifies a two-component format that
has 32 signed float bits in the depth component and 8 unsigned integer
bits in the stencil component.
There are optionally: 24-bits that are unused.
* ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK specifies a three-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data.
This format has no alpha and is considered opaque.
* ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK specifies a three-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data with sRGB
nonlinear encoding.
This format has no alpha and is considered opaque.
* ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK specifies a four-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data, and
provides 1 bit of alpha.
* ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK specifies a four-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data with sRGB
nonlinear encoding, and provides 1 bit of alpha.
* ename:VK_FORMAT_BC2_UNORM_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits
encoding RGB values.
* ename:VK_FORMAT_BC2_SRGB_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits
encoding RGB values with sRGB nonlinear encoding.
* ename:VK_FORMAT_BC3_UNORM_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits
encoding RGB values.
* ename:VK_FORMAT_BC3_SRGB_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data
with the first 64 bits encoding alpha values followed by 64 bits
encoding RGB values with sRGB nonlinear encoding.
* ename:VK_FORMAT_BC4_UNORM_BLOCK specifies a one-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized red texel data.
* ename:VK_FORMAT_BC4_SNORM_BLOCK specifies a one-component,
block-compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of signed normalized red texel data.
* ename:VK_FORMAT_BC5_UNORM_BLOCK specifies a two-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RG texel data with
the first 64 bits encoding red values followed by 64 bits encoding green
values.
* ename:VK_FORMAT_BC5_SNORM_BLOCK specifies a two-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of signed normalized RG texel data with
the first 64 bits encoding red values followed by 64 bits encoding green
values.
* ename:VK_FORMAT_BC6H_UFLOAT_BLOCK specifies a three-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned floating-point RGB texel data.
* ename:VK_FORMAT_BC6H_SFLOAT_BLOCK specifies a three-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of signed floating-point RGB texel data.
* ename:VK_FORMAT_BC7_UNORM_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_BC7_SRGB_BLOCK specifies a four-component,
block-compressed format where each 128-bit compressed texel block
encodes a 4{times}4 rectangle of unsigned normalized RGBA texel data
with sRGB nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK specifies a three-component,
ETC2 compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data.
This format has no alpha and is considered opaque.
* ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK specifies a three-component, ETC2
compressed format where each 64-bit compressed texel block encodes a
4{times}4 rectangle of unsigned normalized RGB texel data with sRGB
nonlinear encoding.
This format has no alpha and is considered opaque.
* ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK specifies a four-component,
ETC2 compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data, and
provides 1 bit of alpha.
* ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK specifies a four-component,
ETC2 compressed format where each 64-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGB texel data with sRGB
nonlinear encoding, and provides 1 bit of alpha.
* ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK specifies a four-component,
ETC2 compressed format where each 128-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGBA texel data with the
first 64 bits encoding alpha values followed by 64 bits encoding RGB
values.
* ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK specifies a four-component,
ETC2 compressed format where each 128-bit compressed texel block encodes
a 4{times}4 rectangle of unsigned normalized RGBA texel data with the
first 64 bits encoding alpha values followed by 64 bits encoding RGB
values with sRGB nonlinear encoding applied.
* ename:VK_FORMAT_EAC_R11_UNORM_BLOCK specifies a one-component, ETC2
compressed format where each 64-bit compressed texel block encodes a
4{times}4 rectangle of unsigned normalized red texel data.
* ename:VK_FORMAT_EAC_R11_SNORM_BLOCK specifies a one-component, ETC2
compressed format where each 64-bit compressed texel block encodes a
4{times}4 rectangle of signed normalized red texel data.
* ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK specifies a two-component, ETC2
compressed format where each 128-bit compressed texel block encodes a
4{times}4 rectangle of unsigned normalized RG texel data with the first
64 bits encoding red values followed by 64 bits encoding green values.
* ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK specifies a two-component, ETC2
compressed format where each 128-bit compressed texel block encodes a
4{times}4 rectangle of signed normalized RG texel data with the first 64
bits encoding red values followed by 64 bits encoding green values.
* ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
4{times}4 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
4{times}4 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
5{times}4 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
5{times}4 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
5{times}5 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
5{times}5 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
6{times}5 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
6{times}5 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
6{times}6 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
6{times}6 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}5 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}5 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}6 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}6 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}8 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes an
8{times}8 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}5 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}5 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}6 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}6 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}8 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}8 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}10 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
10{times}10 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
12{times}10 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
12{times}10 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
* ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
12{times}12 rectangle of unsigned normalized RGBA texel data.
* ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK specifies a four-component, ASTC
compressed format where each 128-bit compressed texel block encodes a
12{times}12 rectangle of unsigned normalized RGBA texel data with sRGB
nonlinear encoding applied to the RGB components.
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
* ename:VK_FORMAT_G8B8G8R8_422_UNORM specifies a four-component, 32-bit
format containing a pair of G components, an R component, and a B
component, collectively encoding a 2{times}1 rectangle of unsigned
normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has an 8-bit G component for the even _i_ coordinate in byte
0, an 8-bit B component in byte 1, an 8-bit G component for the odd _i_
coordinate in byte 2, and an 8-bit R component in byte 3.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_B8G8R8G8_422_UNORM specifies a four-component, 32-bit
format containing a pair of G components, an R component, and a B
component, collectively encoding a 2{times}1 rectangle of unsigned
normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has an 8-bit B component in byte 0, an 8-bit G component for
the even _i_ coordinate in byte 1, an 8-bit R component in byte 2, and
an 8-bit G component for the odd _i_ coordinate in byte 3.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM specifies an unsigned
normalized _multi-planar format_ that has an 8-bit G component in plane
0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2.
The horizontal and vertical dimensions of the R and B planes are halved
relative to the image dimensions, and each R and B component is shared
with the G components for which latexmath:[\lfloor i_G \times 0.5
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
= j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM specifies an unsigned
normalized _multi-planar format_ that has an 8-bit G component in plane
0, and a two-component, 16-bit BR plane 1 consisting of an 8-bit B
component in byte 0 and an 8-bit R component in byte 1.
The horizontal and vertical dimensions of the BR plane is halved
relative to the image dimensions, and each R and B value is shared with
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM specifies an unsigned
normalized _multi-planar format_ that has an 8-bit G component in plane
0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2.
The horizontal dimension of the R and B plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G8_B8R8_2PLANE_422_UNORM specifies an unsigned
normalized _multi-planar format_ that has an 8-bit G component in plane
0, and a two-component, 16-bit BR plane 1 consisting of an 8-bit B
component in byte 0 and an 8-bit R component in byte 1.
The horizontal dimensions of the BR plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM specifies an unsigned
normalized _multi-planar format_ that has an 8-bit G component in plane
0, an 8-bit B component in plane 1, and an 8-bit R component in plane 2.
Each plane has the same dimensions and each R, G and B component
contributes to a single texel.
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
* ename:VK_FORMAT_R10X6_UNORM_PACK16 specifies a one-component, 16-bit
unsigned normalized format that has a single 10-bit R component in the
top 10 bits of a 16-bit word, with the bottom 6 bits set to 0.
* ename:VK_FORMAT_R10X6G10X6_UNORM_2PACK16 specifies a two-component,
32-bit unsigned normalized format that has a 10-bit R component in the
top 10 bits of the word in bytes 0..1, and a 10-bit G component in the
top 10 bits of the word in bytes 2..3, with the bottom 6 bits of each
word set to 0.
* ename:VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 specifies a
four-component, 64-bit unsigned normalized format that has a 10-bit R
component in the top 10 bits of the word in bytes 0..1, a 10-bit G
component in the top 10 bits of the word in bytes 2..3, a 10-bit B
component in the top 10 bits of the word in bytes 4..5, and a 10-bit A
component in the top 10 bits of the word in bytes 6..7, with the bottom
6 bits of each word set to 0.
* ename:VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16 specifies a
four-component, 64-bit format containing a pair of G components, an R
component, and a B component, collectively encoding a 2{times}1
rectangle of unsigned normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 10-bit G component for the even _i_ coordinate in the
top 10 bits of the word in bytes 0..1, a 10-bit B component in the top
10 bits of the word in bytes 2..3, a 10-bit G component for the odd _i_
coordinate in the top 10 bits of the word in bytes 4..5, and a 10-bit R
component in the top 10 bits of the word in bytes 6..7, with the bottom
6 bits of each word set to 0.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16 specifies a
four-component, 64-bit format containing a pair of G components, an R
component, and a B component, collectively encoding a 2{times}1
rectangle of unsigned normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 10-bit B component in the top 10 bits of the word in
bytes 0..1, a 10-bit G component for the even _i_ coordinate in the top
10 bits of the word in bytes 2..3, a 10-bit R component in the top 10
bits of the word in bytes 4..5, and a 10-bit G component for the odd _i_
coordinate in the top 10 bits of the word in bytes 6..7, with the bottom
6 bits of each word set to 0.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 10-bit G component
in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component
in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R
component in the top 10 bits of each 16-bit word of plane 2, with the
bottom 6 bits of each word set to 0.
The horizontal and vertical dimensions of the R and B planes are halved
relative to the image dimensions, and each R and B component is shared
with the G components for which latexmath:[\lfloor i_G \times 0.5
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
= j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 10-bit G component
in the top 10 bits of each 16-bit word of plane 0, and a two-component,
32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits
of the word in bytes 0..1, and a 10-bit R component in the top 10 bits
of the word in bytes 2..3, the bottom 6 bits of each word set to 0.
The horizontal and vertical dimensions of the BR plane is halved
relative to the image dimensions, and each R and B value is shared with
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 10-bit G component
in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component
in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R
component in the top 10 bits of each 16-bit word of plane 2, with the
bottom 6 bits of each word set to 0.
The horizontal dimension of the R and B plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 10-bit G component
in the top 10 bits of each 16-bit word of plane 0, and a two-component,
32-bit BR plane 1 consisting of a 10-bit B component in the top 10 bits
of the word in bytes 0..1, and a 10-bit R component in the top 10 bits
of the word in bytes 2..3, the bottom 6 bits of each word set to 0.
The horizontal dimensions of the BR plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 10-bit G component
in the top 10 bits of each 16-bit word of plane 0, a 10-bit B component
in the top 10 bits of each 16-bit word of plane 1, and a 10-bit R
component in the top 10 bits of each 16-bit word of plane 2, with the
bottom 6 bits of each word set to 0.
Each plane has the same dimensions and each R, G and B component
contributes to a single texel.
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
* ename:VK_FORMAT_R12X4_UNORM_PACK16 specifies a one-component, 16-bit
unsigned normalized format that has a single 12-bit R component in the
top 12 bits of a 16-bit word, with the bottom 4 bits set to 0.
* ename:VK_FORMAT_R12X4G12X4_UNORM_2PACK16 specifies a two-component,
32-bit unsigned normalized format that has a 12-bit R component in the
top 12 bits of the word in bytes 0..1, and a 12-bit G component in the
top 12 bits of the word in bytes 2..3, with the bottom 4 bits of each
word set to 0.
* ename:VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16 specifies a
four-component, 64-bit unsigned normalized format that has a 12-bit R
component in the top 12 bits of the word in bytes 0..1, a 12-bit G
component in the top 12 bits of the word in bytes 2..3, a 12-bit B
component in the top 12 bits of the word in bytes 4..5, and a 12-bit A
component in the top 12 bits of the word in bytes 6..7, with the bottom
4 bits of each word set to 0.
* ename:VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16 specifies a
four-component, 64-bit format containing a pair of G components, an R
component, and a B component, collectively encoding a 2{times}1
rectangle of unsigned normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 12-bit G component for the even _i_ coordinate in the
top 12 bits of the word in bytes 0..1, a 12-bit B component in the top
12 bits of the word in bytes 2..3, a 12-bit G component for the odd _i_
coordinate in the top 12 bits of the word in bytes 4..5, and a 12-bit R
component in the top 12 bits of the word in bytes 6..7, with the bottom
4 bits of each word set to 0.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16 specifies a
four-component, 64-bit format containing a pair of G components, an R
component, and a B component, collectively encoding a 2{times}1
rectangle of unsigned normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 12-bit B component in the top 12 bits of the word in
bytes 0..1, a 12-bit G component for the even _i_ coordinate in the top
12 bits of the word in bytes 2..3, a 12-bit R component in the top 12
bits of the word in bytes 4..5, and a 12-bit G component for the odd _i_
coordinate in the top 12 bits of the word in bytes 6..7, with the bottom
4 bits of each word set to 0.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 12-bit G component
in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component
in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R
component in the top 12 bits of each 16-bit word of plane 2, with the
bottom 4 bits of each word set to 0.
The horizontal and vertical dimensions of the R and B planes are halved
relative to the image dimensions, and each R and B component is shared
with the G components for which latexmath:[\lfloor i_G \times 0.5
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
= j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 12-bit G component
in the top 12 bits of each 16-bit word of plane 0, and a two-component,
32-bit BR plane 1 consisting of a 12-bit B component in the top 12 bits
of the word in bytes 0..1, and a 12-bit R component in the top 12 bits
of the word in bytes 2..3, the bottom 4 bits of each word set to 0.
The horizontal and vertical dimensions of the BR plane is halved
relative to the image dimensions, and each R and B value is shared with
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 12-bit G component
in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component
in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R
component in the top 12 bits of each 16-bit word of plane 2, with the
bottom 4 bits of each word set to 0.
The horizontal dimension of the R and B plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 12-bit G component
in the top 12 bits of each 16-bit word of plane 0, and a two-component,
32-bit BR plane 1 consisting of a 12-bit B component in the top 12 bits
of the word in bytes 0..1, and a 12-bit R component in the top 12 bits
of the word in bytes 2..3, the bottom 4 bits of each word set to 0.
The horizontal dimensions of the BR plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16 specifies an
unsigned normalized _multi-planar format_ that has a 12-bit G component
in the top 12 bits of each 16-bit word of plane 0, a 12-bit B component
in the top 12 bits of each 16-bit word of plane 1, and a 12-bit R
component in the top 12 bits of each 16-bit word of plane 2, with the
bottom 4 bits of each word set to 0.
Each plane has the same dimensions and each R, G and B component
contributes to a single texel.
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
* ename:VK_FORMAT_G16B16G16R16_422_UNORM specifies a four-component,
64-bit format containing a pair of G components, an R component, and a B
component, collectively encoding a 2{times}1 rectangle of unsigned
normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 16-bit G component for the even _i_ coordinate in the
word in bytes 0..1, a 16-bit B component in the word in bytes 2..3, a
16-bit G component for the odd _i_ coordinate in the word in bytes 4..5,
and a 16-bit R component in the word in bytes 6..7.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_B16G16R16G16_422_UNORM specifies a four-component,
64-bit format containing a pair of G components, an R component, and a B
component, collectively encoding a 2{times}1 rectangle of unsigned
normalized RGB texel data.
One G value is present at each _i_ coordinate, with the B and R values
shared across both G values and thus recorded at half the horizontal
resolution of the image.
This format has a 16-bit B component in the word in bytes 0..1, a 16-bit
G component for the even _i_ coordinate in the word in bytes 2..3, a
16-bit R component in the word in bytes 4..5, and a 16-bit G component
for the odd _i_ coordinate in the word in bytes 6..7.
Images in this format must: be defined with a width that is a multiple
of two.
For the purposes of the constraints on copy extents, this format is
treated as a compressed format with a 2{times}1 compressed texel block.
* ename:VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM specifies an unsigned
normalized _multi-planar format_ that has a 16-bit G component in each
16-bit word of plane 0, a 16-bit B component in each 16-bit word of
plane 1, and a 16-bit R component in each 16-bit word of plane 2.
The horizontal and vertical dimensions of the R and B planes are halved
relative to the image dimensions, and each R and B component is shared
with the G components for which latexmath:[\lfloor i_G \times 0.5
\rfloor = i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B
= j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G16_B16R16_2PLANE_420_UNORM specifies an unsigned
normalized _multi-planar format_ that has a 16-bit G component in each
16-bit word of plane 0, and a two-component, 32-bit BR plane 1
consisting of a 16-bit B component in the word in bytes 0..1, and a
16-bit R component in the word in bytes 2..3.
The horizontal and vertical dimensions of the BR plane is halved
relative to the image dimensions, and each R and B value is shared with
the G components for which latexmath:[\lfloor i_G \times 0.5 \rfloor =
i_B = i_R] and latexmath:[\lfloor j_G \times 0.5 \rfloor = j_B = j_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width and height that is a
multiple of two.
* ename:VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM specifies an unsigned
normalized _multi-planar format_ that has a 16-bit G component in each
16-bit word of plane 0, a 16-bit B component in each 16-bit word of
plane 1, and a 16-bit R component in each 16-bit word of plane 2.
The horizontal dimension of the R and B plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G16_B16R16_2PLANE_422_UNORM specifies an unsigned
normalized _multi-planar format_ that has a 16-bit G component in each
16-bit word of plane 0, and a two-component, 32-bit BR plane 1
consisting of a 16-bit B component in the word in bytes 0..1, and a
16-bit R component in the word in bytes 2..3.
The horizontal dimensions of the BR plane is halved relative to the
image dimensions, and each R and B value is shared with the G components
for which latexmath:[\lfloor i_G \times 0.5 \rfloor = i_B = i_R].
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane, and
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the BR plane.
Images in this format must: be defined with a width that is a multiple
of two.
* ename:VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM specifies an unsigned
normalized _multi-planar format_ that has a 16-bit G component in each
16-bit word of plane 0, a 16-bit B component in each 16-bit word of
plane 1, and a 16-bit R component in each 16-bit word of plane 2.
Each plane has the same dimensions and each R, G and B component
contributes to a single texel.
The location of each plane when this image is in linear layout can be
determined via flink:vkGetImageSubresourceLayout, using
ename:VK_IMAGE_ASPECT_PLANE_0_BIT for the G plane,
ename:VK_IMAGE_ASPECT_PLANE_1_BIT for the B plane, and
ename:VK_IMAGE_ASPECT_PLANE_2_BIT for the R plane.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
--
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
[[formats-compatible-planes]]
=== Compatible formats of planes of multi-planar formats
Individual planes of multi-planar formats are _compatible_ with single-plane
formats if they occupy the same number of bits per texel block.
In the following table, individual planes of a _multi-planar_ format are
compatible with the format listed against the relevant plane index for that
multi-planar format.
.Plane Format Compatibility Table
[width="95%",cols="1,6,3,3",options="header"]
|====
^| Plane ^| Compatible format for plane ^| Width relative to the width _w_ of the plane with the largest dimensions ^| Height relative to the height _h_ of the plane with the largest dimensions
4+| *ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM*
^| 0 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R8_UNORM ^| w/2 ^| h/2
^| 2 ^| ename:VK_FORMAT_R8_UNORM ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM*
^| 0 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R8G8_UNORM ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM*
^| 0 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R8_UNORM ^| w/2 ^| h
^| 2 ^| ename:VK_FORMAT_R8_UNORM ^| w/2 ^| h
4+| *ename:VK_FORMAT_G8_B8R8_2PLANE_422_UNORM*
^| 0 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R8G8_UNORM ^| w/2 ^| h
4+| *ename:VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM*
^| 0 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
^| 2 ^| ename:VK_FORMAT_R8_UNORM ^| w ^| h
4+| *ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w/2 ^| h/2
^| 2 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R10X6G10X6_UNORM_2PACK16 ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w/2 ^| h
^| 2 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w/2 ^| h
4+| *ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R10X6G10X6_UNORM_2PACK16 ^| w/2 ^| h
4+| *ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
^| 2 ^| ename:VK_FORMAT_R10X6_UNORM_PACK16 ^| w ^| h
4+| *ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w/2 ^| h/2
^| 2 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R12X4G12X4_UNORM_2PACK16 ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w/2 ^| h
^| 2 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w/2 ^| h
4+| *ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R12X4G12X4_UNORM_2PACK16 ^| w/2 ^| h
4+| *ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16*
^| 0 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
^| 2 ^| ename:VK_FORMAT_R12X4_UNORM_PACK16 ^| w ^| h
4+| *ename:VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM*
^| 0 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R16_UNORM ^| w/2 ^| h/2
^| 2 ^| ename:VK_FORMAT_R16_UNORM ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G16_B16R16_2PLANE_420_UNORM*
^| 0 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R16G16_UNORM ^| w/2 ^| h/2
4+| *ename:VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM*
^| 0 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R16_UNORM ^| w/2 ^| h
^| 2 ^| ename:VK_FORMAT_R16_UNORM ^| w/2 ^| h
4+| *ename:VK_FORMAT_G16_B16R16_2PLANE_422_UNORM*
^| 0 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R16G16_UNORM ^| w/2 ^| h
4+| *ename:VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM*
^| 0 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 1 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
^| 2 ^| ename:VK_FORMAT_R16_UNORM ^| w ^| h
|====
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
[[formats-packed]]
=== Packed Formats
For the purposes of address alignment when accessing buffer memory
containing vertex attribute or texel data, the following formats are
considered _packed_ - whole texels or attributes are stored in bitfields of
a single 8-, 16-, or 32-bit fundamental data type.
* <<formats-packed-8-bit,Packed into 8-bit data types>>:
** ename:VK_FORMAT_R4G4_UNORM_PACK8
* <<formats-packed-16-bit,Packed into 16-bit data types>>:
** ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16
** ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16
** ename:VK_FORMAT_R5G6B5_UNORM_PACK16
** ename:VK_FORMAT_B5G6R5_UNORM_PACK16
** ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16
** ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16
** ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16
* <<formats-packed-32-bit,Packed into 32-bit data types>>:
** ename:VK_FORMAT_A8B8G8R8_UNORM_PACK32
** ename:VK_FORMAT_A8B8G8R8_SNORM_PACK32
** ename:VK_FORMAT_A8B8G8R8_USCALED_PACK32
** ename:VK_FORMAT_A8B8G8R8_SSCALED_PACK32
** ename:VK_FORMAT_A8B8G8R8_UINT_PACK32
** ename:VK_FORMAT_A8B8G8R8_SINT_PACK32
** ename:VK_FORMAT_A8B8G8R8_SRGB_PACK32
** ename:VK_FORMAT_A2R10G10B10_UNORM_PACK32
** ename:VK_FORMAT_A2R10G10B10_SNORM_PACK32
** ename:VK_FORMAT_A2R10G10B10_USCALED_PACK32
** ename:VK_FORMAT_A2R10G10B10_SSCALED_PACK32
** ename:VK_FORMAT_A2R10G10B10_UINT_PACK32
** ename:VK_FORMAT_A2R10G10B10_SINT_PACK32
** ename:VK_FORMAT_A2B10G10R10_UNORM_PACK32
** ename:VK_FORMAT_A2B10G10R10_SNORM_PACK32
** ename:VK_FORMAT_A2B10G10R10_USCALED_PACK32
** ename:VK_FORMAT_A2B10G10R10_SSCALED_PACK32
** ename:VK_FORMAT_A2B10G10R10_UINT_PACK32
** ename:VK_FORMAT_A2B10G10R10_SINT_PACK32
** ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32
** ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
** ename:VK_FORMAT_X8_D24_UNORM_PACK32
=== Identification of Formats
A "`format`" is represented by a single enum value.
The name of a format is usually built up by using the following pattern:
....
VK_FORMAT_{component-format|compression-scheme}_{numeric-format}
....
The component-format indicates either the size of the R, G, B, and A
components (if they are present) in the case of a color format, or the size
of the depth (D) and stencil (S) components (if they are present) in the
case of a depth/stencil format (see below).
An X indicates a component that is unused, but may: be present for padding.
<<<
[[formats-numericformat]]
.Interpretation of Numeric Format
[width="95%",cols="2,10",options="header"]
|====
| Numeric format | Description
| etext:UNORM | The components are unsigned normalized values in the range [eq]#[0,1]#
| etext:SNORM | The components are signed normalized values in the range [eq]#[-1,1]#
| etext:USCALED | The components are unsigned integer values that get converted to floating-point in the range [0,2^n^-1]
| etext:SSCALED | The components are signed integer values that get converted to floating-point in the range [-2^n-1^,2^n-1^-1]
| etext:UINT | The components are unsigned integer values in the range [0,2^n^-1]
| etext:SINT | The components are signed integer values in the range [-2^n-1^,2^n-1^-1]
| etext:UFLOAT | The components are unsigned floating-point numbers (used by packed, shared exponent, and some compressed formats)
| etext:SFLOAT | The components are signed floating-point numbers
| etext:SRGB | The R, G, and B components are unsigned normalized values that represent values using sRGB nonlinear encoding, while the A component (if one exists) is a regular unsigned normalized value
|====
The suffix etext:_PACKnn indicates that the format is packed into an
underlying type with nn bits.
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
The suffix etext:_mPACKnn is a short-hand that indicates that the format has
several components (which may or may not be stored in separate _planes_)
that are each packed into an underlying type with nn bits.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
The suffix etext:_BLOCK indicates that the format is a block-compressed
format, with the representation of multiple pixels encoded interdependently
within a region.
[[formats-compressionscheme]]
.Interpretation of Compression Scheme
[width="95%",cols="2,10",options="header"]
|====
| Compression scheme | Description
| etext:BC | Block Compression. See <<appendix-compressedtex-bc>>.
| etext:ETC2 | Ericsson Texture Compression. See <<appendix-compressedtex-etc2>>.
| etext:EAC | ETC2 Alpha Compression. See <<appendix-compressedtex-etc2>>.
| etext:ASTC | Adaptive Scalable Texture Compression (LDR Profile). See <<appendix-compressedtex-astc>>.
|====
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
For _multi-planar_ images, the components in separate _planes_ are separated
by underscores, and the number of planes is indicated by the addition of a
etext:_2PLANE or etext:_3PLANE suffix.
Similarly, the separate aspects of depth-stencil formats are separated by
underscores, although these are not considered separate planes.
Formats are suffixed by etext:_422 to indicate that planes other than the
first are reduced in size by a factor of two horizontally or that the R and
B values appear at half the horizontal frequency of the G values, etext:_420
to indicate that planes other than the first are reduced in size by a factor
of two both horizontally and vertically, and etext:_444 for consistency to
indicate that all three planes of a three-planar image are the same size.
[NOTE]
.Note
====
No common format has a single plane containing both R and B channels but
does not store these channels at reduced horizontal resolution.
====
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
[[texel-block-size]]
=== Representation and Texel Block Size
Color formats must: be represented in memory in exactly the form indicated
by the format's name.
This means that promoting one format to another with more bits per component
and/or additional components must: not occur for color formats.
Depth/stencil formats have more relaxed requirements as discussed
<<formats-depth-stencil,below>>.
Each format has a _texel block size_, the number of bytes used to store one
_texel block_ (a single addressable element of an uncompressed image, or a
single compressed block of a compressed image).
The texel block size for each format is shown in the
<<formats-compatibility, Compatible formats>> table.
The representation of non-packed formats is that the first component
specified in the name of the format is in the lowest memory addresses and
the last component specified is in the highest memory addresses.
See <<formats-non-packed,Byte mappings for non-packed/compressed color
formats>>.
The in-memory ordering of bytes within a component is determined by the host
endianness.
[[formats-non-packed]]
.Byte mappings for non-packed/compressed color formats
[options="header",cols="16*1,10",width="100%"]
|====
>|0 >|1 >|2 >|3 >|4 >|5 >|6 >|7 >|8 >|9 >|10 >|11 >|12 >|13 >|14 >|15 ^| {leftarrow} Byte
^|R 16+>s|etext:VK_FORMAT_R8_*
^|R ^|G 15+>s|etext:VK_FORMAT_R8G8_*
^|R ^|G ^|B 14+>s|etext:VK_FORMAT_R8G8B8_*
^|B ^|G ^|R 14+>s|etext:VK_FORMAT_B8G8R8_*
^|R ^|G ^|B ^|A 13+>s|etext:VK_FORMAT_R8G8B8A8_*
^|B ^|G ^|R ^|A 13+>s|etext:VK_FORMAT_B8G8R8A8_*
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
^|G~0~ ^|B ^|G~1~ ^|R 13+>s|ename:VK_FORMAT_G8B8G8R8_422_UNORM
^|B ^|G~0~ ^|R ^|G~1~ 13+>s|ename:VK_FORMAT_B8G8R8G8_422_UNORM
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
2+^|R 15+>s|etext:VK_FORMAT_R16_*
2+^|R 2+^|G 13+>s|etext:VK_FORMAT_R16G16_*
2+^|R 2+^|G 2+^|B 11+>s|etext:VK_FORMAT_R16G16B16_*
2+^|R 2+^|G 2+^|B 2+^|A 9+>s|etext:VK_FORMAT_R16G16B16A16_*
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
2+^|G~0~ 2+^|B 2+^|G~1~ 2+^|R 9+>s|etext:VK_FORMAT_G10X6B10X6G10X6R10X6_4PACK16_422_UNORM
etext:VK_FORMAT_G12X4B12X4G12X4R12X4_4PACK16_422_UNORM
etext:VK_FORMAT_G16B16G16R16_UNORM
2+^|B 2+^|G~0~ 2+^|R 2+^|G~1~ 9+>s|etext:VK_FORMAT_B10X6G10X6R10X6G10X6_4PACK16_422_UNORM
etext:VK_FORMAT_B12X4G12X4R12X4G12X4_4PACK16_422_UNORM
ename:VK_FORMAT_B16G16R16G16_422_UNORM
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
4+^|R 13+>s|etext:VK_FORMAT_R32_*
4+^|R 4+^|G 9+>s|etext:VK_FORMAT_R32G32_*
4+^|R 4+^|G 4+^|B 5+>s|etext:VK_FORMAT_R32G32B32_*
4+^|R 4+^|G 4+^|B 4+^|A >s|etext:VK_FORMAT_R32G32B32A32_*
8+^|R 9+>s|etext:VK_FORMAT_R64_*
8+^|R 8+^|G >s|etext:VK_FORMAT_R64G64_*
17+^s|etext:VK_FORMAT_R64G64B64_* as etext:VK_FORMAT_R64G64_* but with B in bytes 16-23
17+^s|etext:VK_FORMAT_R64G64B64A64_* as etext:VK_FORMAT_R64G64B64_* but with A in bytes 24-31
|====
Packed formats store multiple components within one underlying type.
The bit representation is that the first component specified in the name of
the format is in the most-significant bits and the last component specified
is in the least-significant bits of the underlying type.
The in-memory ordering of bytes comprising the underlying type is determined
by the host endianness.
[[formats-packed-8-bit]]
.Bit mappings for packed 8-bit formats
[options="header",cols="8*1",width="100%"]
|====
8+^h| Bit
>|~7~ >|~6~ >|~5~ >|~4~ >|~3~ >|~2~ >|~1~ >|~0~
8+^h| ename:VK_FORMAT_R4G4_UNORM_PACK8
4+^s|R 4+^s|G
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
|====
[[formats-packed-16-bit]]
.Bit mappings for packed 16-bit formats
[options="header",cols="16*1",width="100%"]
|====
16+^h| Bit
>|~15~ >|~14~ >|~13~ >|~12~ >|~11~ >|~10~ >|~9~ >|~8~ >|~7~ >|~6~ >|~5~ >|~4~ >|~3~ >|~2~ >|~1~ >|~0~
16+^h|ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16
4+^s|R 4+^s|G 4+^s|B 4+^s|A
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
16+^h|ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16
4+^s|B 4+^s|G 4+^s|R 4+^s|A
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
16+^h|ename:VK_FORMAT_R5G6B5_UNORM_PACK16
5+^s|R 6+^s|G 5+^s|B
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~5~ ^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
16+^h|ename:VK_FORMAT_B5G6R5_UNORM_PACK16
5+^s|B 6+^s|G 5+^s|R
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~5~ ^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
16+^h|ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16
5+^s|R 5+^s|G 5+^s|B 1+^s|A
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~0~
16+^h|ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16
5+^s|B 5+^s|G 5+^s|R 1+^s|A
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~0~
16+^h|ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16
1+^s|A 5+^s|R 5+^s|G 5+^s|B
^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
16+^h|ename:VK_FORMAT_R10X6_UNORM_PACK16
10+^s|R 6+^s|X
^| ~9~ ^| ~8~ ^| ~7~ ^| ~6~ ^| ~5~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~5~ ^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
16+^h|ename:VK_FORMAT_R12X4_UNORM_PACK16
12+^s|R 4+^s|X
^| ~11~ ^| ~10~
^| ~9~ ^| ~8~ ^| ~7~ ^| ~6~ ^| ~5~
^| ~4~ ^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
^| ~3~ ^| ~2~ ^| ~1~ ^| ~0~
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
|====
[[formats-packed-32-bit]]
.Bit mappings for packed 32-bit formats
[cols="32*1",options="header"]
|====
32+^h|Bit
>|~31~ >|~30~ >|~29~ >|~28~ >|~27~ >|~26~ >|~25~ >|~24~ >|~23~ >|~22~ >|~21~ >|~20~ >|~19~ >|~18~ >|~17~ >|~16~
>|~15~ >|~14~ >|~13~ >|~12~ >|~11~ >|~10~ >|~9~ >|~8~ >|~7~ >|~6~ >|~5~ >|~4~ >|~3~ >|~2~ >|~1~ >|~0~
32+^h|etext:VK_FORMAT_A8B8G8R8_*_PACK32
8+^s|A 8+^s|B 8+^s|G 8+^s|R
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
32+^h|etext:VK_FORMAT_A2R10G10B10_*_PACK32
2+^s|A 10+^s|R 10+^s|G 10+^s|B
^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
32+^h|etext:VK_FORMAT_A2B10G10R10_*_PACK32
2+^s|A 10+^s|B 10+^s|G 10+^s|R
^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
32+^h|ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32
10+^s|B 11+^s|G 11+^s|R
^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~10~ ^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~10~ ^|~9~ ^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
32+^h|ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
5+^s|E 9+^s|B 9+^s|G 9+^s|R
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~8~ ^|~7~ ^|~6~ ^|~5~
^|~4~ ^|~3~ ^|~2~ ^|~1~ ^|~0~
32+^h|ename:VK_FORMAT_X8_D24_UNORM_PACK32
8+^s|X 24+^s|D
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
^|~23~ ^|~22~ ^|~21~ ^|~20~
^|~19~ ^|~18~ ^|~17~ ^|~16~
^|~15~ ^|~14~ ^|~13~ ^|~12~
^|~11~ ^|~10~ ^|~9~ ^|~8~
^|~7~ ^|~6~ ^|~5~ ^|~4~
^|~3~ ^|~2~ ^|~1~ ^|~0~
|====
[[formats-depth-stencil]]
=== Depth/Stencil Formats
Depth/stencil formats are considered opaque and need not be stored in the
exact number of bits per texel or component ordering indicated by the format
enum.
However, implementations must: not substitute a different depth or stencil
precision than that described in the format (e.g. D16 must: not be
implemented as D24 or D32).
[[formats-compatibility-classes]]
=== Format Compatibility Classes
Uncompressed color formats are _compatible_ with each other if they occupy
the same number of bits per texel block.
Compressed color formats are compatible with each other if the only
difference between them is the numerical type of the uncompressed pixels
(e.g. signed vs.
unsigned, or SRGB vs.
UNORM encoding).
Each depth/stencil format is only compatible with itself.
In the <<formats-compatibility,following>> table, all the formats in the
same row are compatible.
[[formats-compatibility]]
.Compatible Formats
[width="90%",cols="4,10",options="header"]
|====
| Class, Texel Block Size, # Texels/Block | Formats
| 8-bit +
Block size 1 byte +
1 texel/block
| ename:VK_FORMAT_R4G4_UNORM_PACK8, +
ename:VK_FORMAT_R8_UNORM, +
ename:VK_FORMAT_R8_SNORM, +
ename:VK_FORMAT_R8_USCALED, +
ename:VK_FORMAT_R8_SSCALED, +
ename:VK_FORMAT_R8_UINT, +
ename:VK_FORMAT_R8_SINT, +
ename:VK_FORMAT_R8_SRGB
| 16-bit +
Block size 2 bytes +
1 texel/block
| ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16, +
ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16, +
ename:VK_FORMAT_R5G6B5_UNORM_PACK16, +
ename:VK_FORMAT_B5G6R5_UNORM_PACK16, +
ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16, +
ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16, +
ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16, +
ename:VK_FORMAT_R8G8_UNORM, +
ename:VK_FORMAT_R8G8_SNORM, +
ename:VK_FORMAT_R8G8_USCALED, +
ename:VK_FORMAT_R8G8_SSCALED, +
ename:VK_FORMAT_R8G8_UINT, +
ename:VK_FORMAT_R8G8_SINT, +
ename:VK_FORMAT_R8G8_SRGB, +
ename:VK_FORMAT_R16_UNORM, +
ename:VK_FORMAT_R16_SNORM, +
ename:VK_FORMAT_R16_USCALED, +
ename:VK_FORMAT_R16_SSCALED, +
ename:VK_FORMAT_R16_UINT, +
ename:VK_FORMAT_R16_SINT, +
ifndef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ename:VK_FORMAT_R16_SFLOAT
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ename:VK_FORMAT_R16_SFLOAT, +
ename:VK_FORMAT_R10X6_UNORM_PACK16, +
ename:VK_FORMAT_R12X4_UNORM_PACK16
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| 24-bit +
Block size 3 bytes +
1 texel/block
| ename:VK_FORMAT_R8G8B8_UNORM, +
ename:VK_FORMAT_R8G8B8_SNORM, +
ename:VK_FORMAT_R8G8B8_USCALED, +
ename:VK_FORMAT_R8G8B8_SSCALED, +
ename:VK_FORMAT_R8G8B8_UINT, +
ename:VK_FORMAT_R8G8B8_SINT, +
ename:VK_FORMAT_R8G8B8_SRGB, +
ename:VK_FORMAT_B8G8R8_UNORM, +
ename:VK_FORMAT_B8G8R8_SNORM, +
ename:VK_FORMAT_B8G8R8_USCALED, +
ename:VK_FORMAT_B8G8R8_SSCALED, +
ename:VK_FORMAT_B8G8R8_UINT, +
ename:VK_FORMAT_B8G8R8_SINT, +
ename:VK_FORMAT_B8G8R8_SRGB
| 32-bit +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_R8G8B8A8_UNORM, +
ename:VK_FORMAT_R8G8B8A8_SNORM, +
ename:VK_FORMAT_R8G8B8A8_USCALED, +
ename:VK_FORMAT_R8G8B8A8_SSCALED, +
ename:VK_FORMAT_R8G8B8A8_UINT, +
ename:VK_FORMAT_R8G8B8A8_SINT, +
ename:VK_FORMAT_R8G8B8A8_SRGB, +
ename:VK_FORMAT_B8G8R8A8_UNORM, +
ename:VK_FORMAT_B8G8R8A8_SNORM, +
ename:VK_FORMAT_B8G8R8A8_USCALED, +
ename:VK_FORMAT_B8G8R8A8_SSCALED, +
ename:VK_FORMAT_B8G8R8A8_UINT, +
ename:VK_FORMAT_B8G8R8A8_SINT, +
ename:VK_FORMAT_B8G8R8A8_SRGB, +
ename:VK_FORMAT_A8B8G8R8_UNORM_PACK32, +
ename:VK_FORMAT_A8B8G8R8_SNORM_PACK32, +
ename:VK_FORMAT_A8B8G8R8_USCALED_PACK32, +
ename:VK_FORMAT_A8B8G8R8_SSCALED_PACK32, +
ename:VK_FORMAT_A8B8G8R8_UINT_PACK32, +
ename:VK_FORMAT_A8B8G8R8_SINT_PACK32, +
ename:VK_FORMAT_A8B8G8R8_SRGB_PACK32, +
ename:VK_FORMAT_A2R10G10B10_UNORM_PACK32, +
ename:VK_FORMAT_A2R10G10B10_SNORM_PACK32, +
ename:VK_FORMAT_A2R10G10B10_USCALED_PACK32, +
ename:VK_FORMAT_A2R10G10B10_SSCALED_PACK32, +
ename:VK_FORMAT_A2R10G10B10_UINT_PACK32, +
ename:VK_FORMAT_A2R10G10B10_SINT_PACK32, +
ename:VK_FORMAT_A2B10G10R10_UNORM_PACK32, +
ename:VK_FORMAT_A2B10G10R10_SNORM_PACK32, +
ename:VK_FORMAT_A2B10G10R10_USCALED_PACK32, +
ename:VK_FORMAT_A2B10G10R10_SSCALED_PACK32, +
ename:VK_FORMAT_A2B10G10R10_UINT_PACK32, +
ename:VK_FORMAT_A2B10G10R10_SINT_PACK32, +
ename:VK_FORMAT_R16G16_UNORM, +
ename:VK_FORMAT_R16G16_SNORM, +
ename:VK_FORMAT_R16G16_USCALED, +
ename:VK_FORMAT_R16G16_SSCALED, +
ename:VK_FORMAT_R16G16_UINT, +
ename:VK_FORMAT_R16G16_SINT, +
ename:VK_FORMAT_R16G16_SFLOAT, +
ename:VK_FORMAT_R32_UINT, +
ename:VK_FORMAT_R32_SINT, +
ename:VK_FORMAT_R32_SFLOAT, +
ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32, +
ifndef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32, +
ename:VK_FORMAT_R10X6G10X6_UNORM_2PACK16, +
ename:VK_FORMAT_R12X4G12X4_UNORM_2PACK16
| 32-bit G8B8G8R8 +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_G8B8G8R8_422_UNORM
| 32-bit B8G8R8G8 +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_B8G8R8G8_422_UNORM
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| 48-bit +
Block size 6 bytes +
1 texel/block
| ename:VK_FORMAT_R16G16B16_UNORM, +
ename:VK_FORMAT_R16G16B16_SNORM, +
ename:VK_FORMAT_R16G16B16_USCALED, +
ename:VK_FORMAT_R16G16B16_SSCALED, +
ename:VK_FORMAT_R16G16B16_UINT, +
ename:VK_FORMAT_R16G16B16_SINT, +
ename:VK_FORMAT_R16G16B16_SFLOAT
| 64-bit +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_R16G16B16A16_UNORM, +
ename:VK_FORMAT_R16G16B16A16_SNORM, +
ename:VK_FORMAT_R16G16B16A16_USCALED, +
ename:VK_FORMAT_R16G16B16A16_SSCALED, +
ename:VK_FORMAT_R16G16B16A16_UINT, +
ename:VK_FORMAT_R16G16B16A16_SINT, +
ename:VK_FORMAT_R16G16B16A16_SFLOAT, +
ename:VK_FORMAT_R32G32_UINT, +
ename:VK_FORMAT_R32G32_SINT, +
ename:VK_FORMAT_R32G32_SFLOAT, +
ename:VK_FORMAT_R64_UINT, +
ename:VK_FORMAT_R64_SINT, +
ename:VK_FORMAT_R64_SFLOAT
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| 64-bit R10G10B10A10 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16
| 64-bit G10B10G10R10 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16
| 64-bit B10G10R10G10 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16
| 64-bit R12G12B12A12 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16
| 64-bit G12B12G12R12 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16
| 64-bit B12G12R12G12 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16
| 64-bit G16B16G16R16 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_G16B16G16R16_422_UNORM
| 64-bit B16G16R16G16 +
Block size 8 bytes +
1 texel/block
| ename:VK_FORMAT_B16G16R16G16_422_UNORM
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| 96-bit +
Block size 12 bytes +
1 texel/block
| ename:VK_FORMAT_R32G32B32_UINT, +
ename:VK_FORMAT_R32G32B32_SINT, +
ename:VK_FORMAT_R32G32B32_SFLOAT
| 128-bit +
Block size 16 bytes +
1 texel/block
| ename:VK_FORMAT_R32G32B32A32_UINT, +
ename:VK_FORMAT_R32G32B32A32_SINT, +
ename:VK_FORMAT_R32G32B32A32_SFLOAT, +
ename:VK_FORMAT_R64G64_UINT, +
ename:VK_FORMAT_R64G64_SINT, +
ename:VK_FORMAT_R64G64_SFLOAT
| 192-bit +
Block size 24 bytes +
1 texel/block
| ename:VK_FORMAT_R64G64B64_UINT, +
ename:VK_FORMAT_R64G64B64_SINT, +
ename:VK_FORMAT_R64G64B64_SFLOAT
| 256-bit +
Block size 32 bytes +
1 texel/block
| ename:VK_FORMAT_R64G64B64A64_UINT, +
ename:VK_FORMAT_R64G64B64A64_SINT, +
ename:VK_FORMAT_R64G64B64A64_SFLOAT
| BC1_RGB (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK, +
ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK
| BC1_RGBA (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK, +
ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK
| BC2 (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_BC2_UNORM_BLOCK, +
ename:VK_FORMAT_BC2_SRGB_BLOCK
| BC3 (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_BC3_UNORM_BLOCK, +
ename:VK_FORMAT_BC3_SRGB_BLOCK
| BC4 (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_BC4_UNORM_BLOCK, +
ename:VK_FORMAT_BC4_SNORM_BLOCK
| BC5 (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_BC5_UNORM_BLOCK, +
ename:VK_FORMAT_BC5_SNORM_BLOCK
| BC6H (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_BC6H_UFLOAT_BLOCK, +
ename:VK_FORMAT_BC6H_SFLOAT_BLOCK
| BC7 (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_BC7_UNORM_BLOCK, +
ename:VK_FORMAT_BC7_SRGB_BLOCK
| ETC2_RGB (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK, +
ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK
| ETC2_RGBA (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK, +
ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK
| ETC2_EAC_RGBA (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK, +
ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK
| EAC_R (64 bit) +
Block size 8 bytes +
16 texels/block
| ename:VK_FORMAT_EAC_R11_UNORM_BLOCK, +
ename:VK_FORMAT_EAC_R11_SNORM_BLOCK
| EAC_RG (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK, +
ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK
| ASTC_4x4 (128 bit) +
Block size 16 bytes +
16 texels/block
| ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK
| ASTC_5x4 (128 bit) +
Block size 16 bytes +
20 texels/block
| ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK
| ASTC_5x5 (128 bit) +
Block size 16 bytes +
25 texels/block
| ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK
| ASTC_6x5 (128 bit) +
Block size 16 bytes +
30 texels/block
| ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK
| ASTC_6x6 (128 bit) +
Block size 16 bytes +
36 texels/block
| ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK
| ASTC_8x5 (128 bit) +
Block size 16 bytes +
40 texels/block
| ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK
| ASTC_8x6 (128 bit) +
Block size 16 bytes +
48 texels/block
| ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK
| ASTC_8x8 (128 bit) +
Block size 16 bytes +
64 texels/block
| ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK
| ASTC_10x5 (128 bit) +
Block size 16 bytes +
50 texels/block
| ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK
| ASTC_10x6 (128 bit) +
Block size 16 bytes +
60 texels/block
| ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK
| ASTC_10x8 (128 bit) +
Block size 16 bytes +
80 texels/block
| ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK
| ASTC_10x10 (128 bit) +
Block size 16 bytes +
100 texels/block
| ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK
| ASTC_12x10 (128 bit) +
Block size 16 bytes +
120 texels/block
| ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK
| ASTC_12x12 (128 bit) +
Block size 16 bytes +
144 texels/block
| ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK, +
ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK
| D16 (16 bit) +
Block size 2 bytes +
1 texel/block
| ename:VK_FORMAT_D16_UNORM
| D24 (32 bit) +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_X8_D24_UNORM_PACK32
| D32 (32 bit) +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_D32_SFLOAT
| S8 (8 bit) +
Block size 1 byte +
1 texel/block
| ename:VK_FORMAT_S8_UINT
| D16S8 (24 bit) +
Block size 3 bytes +
1 texel/block
| ename:VK_FORMAT_D16_UNORM_S8_UINT
| D24S8 (32 bit) +
Block size 4 bytes +
1 texel/block
| ename:VK_FORMAT_D24_UNORM_S8_UINT
| D32S8 (40 bit) +
Block size 5 bytes +
1 texel/block
| ename:VK_FORMAT_D32_SFLOAT_S8_UINT
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
| 8-bit 3-plane 420 +
Block size (1,1,1) bytes +
1 texel/block
| ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM
| 8-bit 2-plane 420 +
Block size (1,2) bytes +
1 texel/block
| ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM
| 8-bit 3-plane 422 +
Block size (1,1,1) bytes +
1 texel/block
| ename:VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM
| 8-bit 2-plane 422 +
Block size (1,2) bytes +
1 texel/block
| ename:VK_FORMAT_G8_B8R8_2PLANE_422_UNORM
| 8-bit 3-plane 444 +
Block size (1,1,1) bytes +
1 texel/block
| ename:VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM
| 10-bit 3-plane 420 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16
| 10-bit 2-plane 420 +
Block size (2,4) bytes +
1 texel/block
| ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16
| 10-bit 3-plane 422 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16
| 10-bit 2-plane 422 +
Block size (2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16
| 10-bit 3-plane 444 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16
| 12-bit 3-plane 420 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16
| 12-bit 2-plane 420 +
Block size (2,4) bytes +
1 texel/block
| ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16
| 12-bit 3-plane 422 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16
| 12-bit 2-plane 422 +
Block size (2,4) bytes +
1 texel/block
| ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16
| 12-bit 3-plane 444 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16
| 16-bit 3-plane 420 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM
| 16-bit 2-plane 420 +
Block size (2,4) bytes +
1 texel/block
| ename:VK_FORMAT_G16_B16R16_2PLANE_420_UNORM
| 16-bit 3-plane 422 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM
| 16-bit 2-plane 422 +
Block size (2,4) bytes +
1 texel/block
| ename:VK_FORMAT_G16_B16R16_2PLANE_422_UNORM
| 16-bit 3-plane 444 +
Block size (2,2,2) bytes +
1 texel/block
| ename:VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
|====
[[formats-properties]]
== Format Properties
[open,refpage='vkGetPhysicalDeviceFormatProperties',desc='Lists physical device\'s format capabilities',type='protos']
--
To query supported format features which are properties of the physical
device, call:
2019-04-16 12:19:43 +00:00
include::{generated}/api/protos/vkGetPhysicalDeviceFormatProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:physicalDevice is the physical device from which to query the
format properties.
* pname:format is the format whose properties are queried.
* pname:pFormatProperties is a pointer to a slink:VkFormatProperties
structure in which physical device properties for pname:format are
returned.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/protos/vkGetPhysicalDeviceFormatProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkFormatProperties',desc='Structure specifying image format properties',type='structs']
--
The sname:VkFormatProperties structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkFormatProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:linearTilingFeatures is a bitmask of elink:VkFormatFeatureFlagBits
specifying features supported by images created with a pname:tiling
parameter of ename:VK_IMAGE_TILING_LINEAR.
* pname:optimalTilingFeatures is a bitmask of
elink:VkFormatFeatureFlagBits specifying features supported by images
created with a pname:tiling parameter of ename:VK_IMAGE_TILING_OPTIMAL.
* pname:bufferFeatures is a bitmask of elink:VkFormatFeatureFlagBits
specifying features supported by buffers.
[NOTE]
.Note
====
ifndef::VK_VERSION_1_1,VK_KHR_maintenance1[]
If no format feature flags are supported, then the only possible use would
be image transfers - which alone are not useful.
As such, if no format feature flags are supported, the format itself is not
supported, and images of that format cannot be created.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
If no format feature flags are supported, the format itself is not
supported, and images of that format cannot be created.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
====
If pname:format is a block-compressed format, then pname:bufferFeatures
must: not support any features for the format.
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
2019-03-11 09:10:05 +00:00
If pname:format is not a multi-plane format then pname:linearTilingFeatures
and pname:optimalTilingFeatures must: not contain
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
ename:VK_FORMAT_FEATURE_DISJOINT_BIT.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkFormatProperties.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkFormatFeatureFlagBits',desc='Bitmask specifying features supported by a buffer',type='enums']
--
Bits which can: be set in the slink:VkFormatProperties features
pname:linearTilingFeatures, pname:optimalTilingFeatures,
ifdef::VK_EXT_image_drm_format_modifier[]
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierTilingFeatures>>,
endif::VK_EXT_image_drm_format_modifier[]
and pname:bufferFeatures are:
2019-04-16 12:19:43 +00:00
include::{generated}/api/enums/VkFormatFeatureFlagBits.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
The following bits may: be set in
ifndef::VK_EXT_image_drm_format_modifier[]
pname:linearTilingFeatures and pname:optimalTilingFeatures,
endif::VK_EXT_image_drm_format_modifier[]
ifdef::VK_EXT_image_drm_format_modifier[]
pname:linearTilingFeatures, pname:optimalTilingFeatures, and
<<VkDrmFormatModifierPropertiesEXT,pname:drmFormatModifierTilingFeatures>>,
endif::VK_EXT_image_drm_format_modifier[]
specifying that the features are supported by <<VkImage,images>> or
<<VkImageView,image views>> created with the queried
flink:vkGetPhysicalDeviceFormatProperties::pname:format:
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT specifies that an image view
can: be <<descriptorsets-sampledimage, sampled from>>.
* ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT specifies that an image view
can: be used as a <<descriptorsets-storageimage, storage images>>.
* ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT specifies that an image
view can: be used as storage image that supports atomic operations.
* ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT specifies that an image
view can: be used as a framebuffer color attachment and as an input
attachment.
* ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT specifies that an
image view can: be used as a framebuffer color attachment that supports
blending and as an input attachment.
* ename:VK_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.
* ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT specifies that an image can: be
used as pname:srcImage for the fname:vkCmdBlitImage command.
* ename:VK_FORMAT_FEATURE_BLIT_DST_BIT specifies that an image can: be
used as pname:dstImage for the fname:vkCmdBlitImage command.
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT specifies that
if ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT is also set, an image view
can: be used with a sampler that has either of pname:magFilter or
pname:minFilter set to ename:VK_FILTER_LINEAR, or pname:mipmapMode set
to ename:VK_SAMPLER_MIPMAP_MODE_LINEAR.
If ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT is also set, an image can be
used as the pname:srcImage to flink:vkCmdBlitImage with a pname:filter
of ename:VK_FILTER_LINEAR.
This bit must: only be exposed for formats that also support the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT or
ename:VK_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.
If this bit is not present, linear filtering with depth compare disabled is
unsupported and linear filtering with depth compare enabled is supported,
but may: compute the filtered value in an implementation-dependent manner
which differs from the normal rules of linear filtering.
The resulting value must: be in the range [eq]#[0,1]# and should: be
proportional to, or a weighted average of, the number of comparison passes
or failures.
ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
* ename:VK_FORMAT_FEATURE_TRANSFER_SRC_BIT specifies that an image can: be
used as a source image for <<copies, copy commands>>.
* ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT specifies that an image can: be
used as a destination image for <<copies, copy commands>> and <<clears,
clear commands>>.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
ifdef::VK_EXT_sampler_filter_minmax[]
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT specifies
sname:VkImage can: be used as a sampled image with a min or max
elink:VkSamplerReductionModeEXT.
This bit must: only be exposed for formats that also support the
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT.
endif::VK_EXT_sampler_filter_minmax[]
ifdef::VK_IMG_filter_cubic,VK_EXT_filter_cubic[]
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT specifies
that sname:VkImage can: be used with a sampler that has either of
pname:magFilter or pname:minFilter set to ename:VK_FILTER_CUBIC_EXT, or
be the source image for a blit with pname:filter set to
ename:VK_FILTER_CUBIC_EXT.
This bit must: only be exposed for formats that also support the
ename:VK_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.
endif::VK_IMG_filter_cubic,VK_EXT_filter_cubic[]
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
* ename:VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT specifies that an
application can: define a <<samplers-YCbCr-conversion,sampler Y'C~B~C~R~
conversion>> using this format as a source, and that an image of this
format can: be used with a sname:VkSamplerYcbcrConversionCreateInfo
pname:xChromaOffset and/or pname:yChromaOffset of
ename:VK_CHROMA_LOCATION_MIDPOINT.
Otherwise both pname:xChromaOffset and pname:yChromaOffset must: be
ename:VK_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'C~B~C~R~ conversion for this format, the implementation must: set
ename:VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT.
* ename:VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT specifies that an
application can: define a <<samplers-YCbCr-conversion,sampler Y'C~B~C~R~
conversion>> using this format as a source, and that an image of this
format can: be used with a sname:VkSamplerYcbcrConversionCreateInfo
pname:xChromaOffset and/or pname:yChromaOffset of
ename:VK_CHROMA_LOCATION_COSITED_EVEN.
Otherwise both pname:xChromaOffset and pname:yChromaOffset must: be
ename:VK_CHROMA_LOCATION_MIDPOINT.
If neither ename:VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT nor
ename:VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT is set, the
application must: not define a <<samplers-YCbCr-conversion,sampler
Y'C~B~C~R~ conversion>> using this format as a source.
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT
specifies that the format can do linear sampler filtering
(min/magFilter) whilst sampler Y'C~B~C~R~ conversion is enabled.
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT
specifies that the format can have different chroma, min, and mag
filters.
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT
specifies that reconstruction is explicit, as described in
<<textures-chroma-reconstruction>>.
If this bit is not present, reconstruction is implicit by default.
* ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT
specifies that reconstruction can: be forcibly made explicit by setting
slink:VkSamplerYcbcrConversionCreateInfo::pname:forceExplicitReconstruction
to ename:VK_TRUE.
* ename:VK_FORMAT_FEATURE_DISJOINT_BIT specifies that a multi-planar image
can: have the ename:VK_IMAGE_CREATE_DISJOINT_BIT set during image
creation.
An implementation must: not set ename:VK_FORMAT_FEATURE_DISJOINT_BIT for
_single-plane formats_.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_EXT_fragment_density_map[]
* ename:VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT specifies that an
image view can: be used as a
<<renderpass-fragmentdensitymapattachment,fragment density map
attachment>>.
endif::VK_EXT_fragment_density_map[]
The following bits may: be set in pname:bufferFeatures, specifying that the
features are supported by <<VkBuffer,buffers>> or <<VkBufferView,buffer
views>> created with the queried
flink:vkGetPhysicalDeviceProperties::pname:format:
* ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT specifies that the
format can: be used to create a buffer view that can: be bound to a
ename:VK_DESCRIPTOR_TYPE_UNIFORM_TEXEL_BUFFER descriptor.
* ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT specifies that the
format can: be used to create a buffer view that can: be bound to a
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER descriptor.
* ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT specifies that
atomic operations are supported on
ename:VK_DESCRIPTOR_TYPE_STORAGE_TEXEL_BUFFER with this format.
* ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT specifies that the format can:
be used as a vertex attribute format
(sname:VkVertexInputAttributeDescription::pname:format).
--
[open,refpage='VkFormatFeatureFlags',desc='Bitmask of VkFormatFeatureFlagBits',type='flags']
--
2019-04-16 12:19:43 +00:00
include::{generated}/api/flags/VkFormatFeatureFlags.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
tname:VkFormatFeatureFlags is a bitmask type for setting a mask of zero or
more elink:VkFormatFeatureFlagBits.
--
ifdef::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
[open,refpage='vkGetPhysicalDeviceFormatProperties2',desc='Lists physical device\'s format capabilities',type='protos']
--
To query supported format features which are properties of the physical
device, call:
ifdef::VK_VERSION_1_1[]
2019-04-16 12:19:43 +00:00
include::{generated}/api/protos/vkGetPhysicalDeviceFormatProperties2.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_VERSION_1_1[]
ifdef::VK_VERSION_1_1+VK_KHR_get_physical_device_properties2[or the equivalent command]
ifdef::VK_KHR_get_physical_device_properties2[]
2019-04-16 12:19:43 +00:00
include::{generated}/api/protos/vkGetPhysicalDeviceFormatProperties2KHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_KHR_get_physical_device_properties2[]
* pname:physicalDevice is the physical device from which to query the
format properties.
* pname:format is the format whose properties are queried.
* pname:pFormatProperties is a pointer to a slink:VkFormatProperties2
structure in which physical device properties for pname:format are
returned.
fname:vkGetPhysicalDeviceFormatProperties2 behaves similarly to
flink:vkGetPhysicalDeviceFormatProperties, with the ability to return
extended information in a pname:pNext chain of output structures.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/protos/vkGetPhysicalDeviceFormatProperties2.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkFormatProperties2',desc='Structure specifying image format properties',type='structs']
--
The sname:VkFormatProperties2 structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkFormatProperties2.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
ifdef::VK_KHR_get_physical_device_properties2[]
or the equivalent
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkFormatProperties2KHR.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
endif::VK_KHR_get_physical_device_properties2[]
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:formatProperties is a structure of type slink:VkFormatProperties
describing features supported by the requested format.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkFormatProperties2.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
ifdef::VK_EXT_image_drm_format_modifier[]
[open,refpage='VkDrmFormatModifierPropertiesListEXT',desc='Structure specifying the list of DRM format modifiers supported for a format',type='structs']
--
To obtain the list of <<glossary-drm-format-modifier,Linux DRM format
modifiers>> compatible with a elink:VkFormat, add
slink:VkDrmFormatModifierPropertiesListEXT to the pname:pNext chain of
slink:VkFormatProperties2.
The slink:VkDrmFormatModifierPropertiesListEXT structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkDrmFormatModifierPropertiesListEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:sType is the type of this structure.
* pname:pNext is `NULL` or a pointer to an extension-specific structure.
* pname:drmFormatModifierCount is an inout parameter related to the number
of modifiers compatible with the pname:format, as described below.
* pname:pDrmFormatModifierProperties is either `NULL` or an array of
slink:VkDrmFormatModifierPropertiesEXT structures.
If pname:pDrmFormatModifierProperties is `NULL`, then the function returns
in pname:drmFormatModifierCount the number of modifiers compatible with the
queried pname:format.
Otherwise, the application must: set pname:drmFormatModifierCount to the
length of the array pname:pDrmFormatModifierProperties; the function will
write at most pname:drmFormatModifierCount elements to the array, and will
return in pname:drmFormatModifierCount the number of elements written.
Among the elements in array pname:pDrmFormatModifierProperties, each
returned pname:drmFormatModifier must: be unique.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkDrmFormatModifierPropertiesListEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
[open,refpage='VkDrmFormatModifierPropertiesEXT',desc='Structure specifying properties of a format when combined with a DRM format modifier',type='structs']
--
The slink:VkDrmFormatModifierPropertiesEXT structure describes properties of
a elink:VkFormat when that format is combined with a
<<glossary-drm-format-modifier,Linux DRM format modifier>>.
These properties, like those of slink:VkFormatProperties2, are independent
of any particular image.
The slink:VkDrmFormatModifierPropertiesEXT structure is defined as:
2019-04-16 12:19:43 +00:00
include::{generated}/api/structs/VkDrmFormatModifierPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
* pname:drmFormatModifier is a _Linux DRM format modifier_.
* pname:drmFormatModifierPlaneCount is the number of _memory planes_ in
any image created with pname:format and pname:drmFormatModifier.
An image's _memory planecount_ is distinct from its _format planecount_,
as explained below.
* pname:drmFormatModifierTilingFeatures is a bitmask of
elink:VkFormatFeatureFlagBits that are supported by any image created
with pname:format and pname:drmFormatModifier.
The returned pname:drmFormatModifierTilingFeatures must: contain at least
one bit.
The implementation must: not return etext:DRM_FORMAT_MOD_INVALID in
pname:drmFormatModifier.
An image's _memory planecount_ (as returned by
pname:drmFormatModifierPlaneCount) is distinct from its _format planecount_
(in the sense of <<formats-requiring-sampler-ycbcr-conversion,multi-planar>>
Y'C~B~C~R~ formats).
In tlink:VkImageAspectFlags, each
etext:VK_IMAGE_ASPECT_MEMORY_PLANE___i___BIT_EXT represents a _memory plane_
and each etext: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 channels.
The ordered partition is encoded in the name of each elink:VkFormat.
For example, ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM contains two _format
planes_; the first plane contains the green channel and the second plane
contains the blue channel and red channel.
If the format name does not contain `PLANE`, then the format contains a
single plane; for example, ename:VK_FORMAT_R8G8B8A8_UNORM.
Some commands, such as flink:vkCmdCopyBufferToImage, do not operate on all
format channels 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 <<glossary-linear-resource,linear>>, then the partition is
the same for _memory planes_ and for _format planes_.
Therefore, if the returned pname:drmFormatModifier is
code:DRM_FORMAT_MOD_LINEAR, then pname:drmFormatModifierPlaneCount must:
equal the _format planecount_, and pname:drmFormatModifierTilingFeatures
must: be identical to the
slink:VkFormatProperties2::pname:linearTilingFeatures returned in the same
pname:pNext chain.
If an image is <<glossary-linear-resource,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 pname:format is
ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM, pname:tiling is
ename:VK_IMAGE_TILING_DRM_FORMAT_MODIFIER_EXT, whose pname:drmFormatModifier
is not code:DRM_FORMAT_MOD_LINEAR, and pname:flags lacks
ename:VK_IMAGE_CREATE_DISJOINT_BIT.
The image has 3 _format planes_, and commands such
flink:vkCmdCopyBufferToImage 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 channels 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
pname:drmFormatModifierPlaneCount.
In all other cases, the _memory planecount_ is ignored.
2019-04-16 12:19:43 +00:00
include::{generated}/validity/structs/VkDrmFormatModifierPropertiesEXT.txt[]
Change log for March 3, 2019 Vulkan 1.1.102 spec update:
* Update release number to 102.
Public Issues:
* Simplify flink:vkGetImageMemoryRequirements constraint for
ename:VK_MEMORY_PROPERTY_LAZILY_ALLOCATED_BIT (public pull request 817).
* Fix typo in markup of the <<textures-texel-coordinate-systems-diagrams,
Texel Coordinate Systems, Corner Sampling>> image that was generating
complaints from chunked HTML output generation (public pull request
928).
Internal Issues:
* Split the old <<features, Features>> chapter into four chapters:
<<features, Features>>, <<limits, Limits>>, <<formats, Formats>>, and
<<capabilities, Capabilities>>, with minor edits to the introductory
paragraph of each chapter. Anchor names in these chapters were changed,
with corresponding effects to xrefs to these anchors elsewhere in spec
markup . The purpose is to make the chunked HTML spec output load faster
on what was previously a single, gigantic chapter (internal issue 1554).
* Add ename:VK_PIPELINE_STAGE_RAY_TRACING_SHADER_BIT_NV, to the supported
pipeline stages for ename:VK_ACCESS_UNIFORM_READ,
ename:VK_ACCESS_SHADER_READ, and ename:VK_ACCESS_SHADER_WRITE in the
<<synchronization-access-types-supported>> table.
* Correct legal name of Google, LLC in vk.xml \<tags> section and a
copyright statement.
* Clarify that Vulkan treats the Android
code:AHARDWAREBUFFER_FORMAT_R8G8B8X8_UNORM format as RGBA, and the
application is responsible for forcing the X/A component to be read as
1.0, in the <<memory-external-android-hardware-buffer-formats>> table.
* Clarify the vertex order of various primitive topologies, and define the
order of transform feedback vertex capture based on that. This involves
a lot of refactoring and cleanup in the <<drawing-primitive-topologies,
Primitive Topologies>>, <<geometry-input, Geometry Shader Input
Primitives>> sections, and <<vertexpostproc-transform-feedback Transform
Feedback>> sections, and numerous places in the <<tessellation>>
chapter,
New Extensions:
* `VK_EXT_metal_surface`
* `VK_EXT_ycbcr_image_arrays` (internal issue 1361).
* `VK_NVX_image_view_handle`
2019-03-04 05:05:48 +00:00
--
endif::VK_EXT_image_drm_format_modifier[]
endif::VK_VERSION_1_1,VK_KHR_get_physical_device_properties2[]
[[features-required-format-support]]
== Required Format Support
Implementations must: support at least the following set of features on the
listed formats.
For images, these features must: be supported for every elink:VkImageType
(including arrayed and cube variants) unless otherwise noted.
These features are supported on existing formats without needing to
advertise an extension or needing to explicitly enable them.
Support for additional functionality beyond the requirements listed here is
queried using the flink:vkGetPhysicalDeviceFormatProperties command.
[NOTE]
.Note
====
Unless otherwise excluded below, the required formats are supported for all
tlink:VkImageCreateFlags values as long as those flag values are otherwise
allowed.
====
The following tables show which feature bits must: be supported for each
format.
ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
Formats that are required to support
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT must: also support
ename:VK_FORMAT_FEATURE_TRANSFER_SRC_BIT and
ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT.
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
.Key for format feature tables
[width="70%",cols="1,10"]
|====
^|{sym1} | This feature must: be supported on the named format
^|{sym2} | This feature must: be supported on at least some
of the named formats, with more information in the table
where the symbol appears
|====
.Feature bits in pname:optimalTilingFeatures
[width="70%"]
|====
ifdef::VK_VERSION_1_1,VK_KHR_maintenance1[]
|ename:VK_FORMAT_FEATURE_TRANSFER_SRC_BIT
|ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT
endif::VK_VERSION_1_1,VK_KHR_maintenance1[]
|ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT
|ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT
|ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT
|ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT
|ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT
|ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT
|ename:VK_FORMAT_FEATURE_BLIT_DST_BIT
|ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT
|ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT
ifdef::VK_EXT_sampler_filter_minmax[]
|ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_MINMAX_BIT_EXT
endif::VK_EXT_sampler_filter_minmax[]
|====
.Feature bits in pname:bufferFeatures
[width="70%"]
|====
|ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT
|ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT
|ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT
|ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT
|====
<<<
[[formats-mandatory-features-subbyte]]
.Mandatory format support: sub-byte channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_UNDEFINED | | | | | | | | | | | | |
| ename:VK_FORMAT_R4G4_UNORM_PACK8 | | | | | | | | | | | | |
| ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16 | | | | | | | | | | | | |
| ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16 | {sym1} | {sym1} | {sym1} | | | | | | | | | |
| ename:VK_FORMAT_R5G6B5_UNORM_PACK16 | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | | | |
| ename:VK_FORMAT_B5G6R5_UNORM_PACK16 | | | | | | | | | | | | |
| ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16 | | | | | | | | | | | | |
| ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16 | | | | | | | | | | | | |
| ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16 | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | | | |
|====
<<<
[[formats-mandatory-features-2byte]]
.Mandatory format support: 1-3 byte-sized channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_R8_UNORM | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8_SNORM | {sym1} | {sym1} | {sym1} | | | | | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8_UINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8_SINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8_SRGB | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8_UNORM | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8G8_SNORM | {sym1} | {sym1} | {sym1} | | | | | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8G8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8_UINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8G8_SINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R8G8_SRGB | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_UNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_SNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8_SRGB | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_UNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_SNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8_SRGB | | | | | | | | | | | | |
|====
<<<
[[formats-mandatory-features-4byte]]
.Mandatory format support: 4 byte-sized channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_R8G8B8A8_UNORM | {sym1} | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R8G8B8A8_SNORM | {sym1} | {sym1} | {sym1} | {sym1} | | | | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R8G8B8A8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8A8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R8G8B8A8_UINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R8G8B8A8_SINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R8G8B8A8_SRGB | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | | | |
| ename:VK_FORMAT_B8G8R8A8_UNORM | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_B8G8R8A8_SNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8A8_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8A8_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8A8_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8A8_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8A8_SRGB | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | | | |
| ename:VK_FORMAT_A8B8G8R8_UNORM_PACK32 | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_A8B8G8R8_SNORM_PACK32 | {sym1} | {sym1} | {sym1} | | | | | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_A8B8G8R8_USCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A8B8G8R8_SSCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A8B8G8R8_UINT_PACK32 | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_A8B8G8R8_SINT_PACK32 | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_A8B8G8R8_SRGB_PACK32 | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | | | |
|====
<<<
[[formats-mandatory-features-10bit]]
.Mandatory format support: 10-bit channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_A2R10G10B10_UNORM_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2R10G10B10_SNORM_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2R10G10B10_USCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2R10G10B10_SSCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2R10G10B10_UINT_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2R10G10B10_SINT_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2B10G10R10_UNORM_PACK32 | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_A2B10G10R10_SNORM_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2B10G10R10_USCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2B10G10R10_SSCALED_PACK32 | | | | | | | | | | | | |
| ename:VK_FORMAT_A2B10G10R10_UINT_PACK32 | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | | {sym1} | |
| ename:VK_FORMAT_A2B10G10R10_SINT_PACK32 | | | | | | | | | | | | |
|====
<<<
[[formats-mandatory-features-16bit]]
.Mandatory format support: 16-bit channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_R16_UNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16_SNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16_UINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16_SINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16_SFLOAT | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16G16_UNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16G16_SNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16G16_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16_UINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16G16_SINT | {sym1} | {sym1} | | | | {sym1} | {sym1} | | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16G16_SFLOAT | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | |
| ename:VK_FORMAT_R16G16B16_UNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_SNORM | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16_SFLOAT | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16A16_UNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16G16B16A16_SNORM | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R16G16B16A16_USCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16A16_SSCALED | | | | | | | | | | | | |
| ename:VK_FORMAT_R16G16B16A16_UINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R16G16B16A16_SINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R16G16B16A16_SFLOAT | {sym1} | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} |
|====
<<<
[[formats-mandatory-features-32bit]]
.Mandatory format support: 32-bit channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_R32_UINT | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | {sym1}
| ename:VK_FORMAT_R32_SINT | {sym1} | {sym1} | | {sym1} | {sym1} | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} | {sym1}
| ename:VK_FORMAT_R32_SFLOAT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32_UINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32_SINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32_SFLOAT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32B32_UINT | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R32G32B32_SINT | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R32G32B32_SFLOAT | | | | | | | | | | {sym1} | | |
| ename:VK_FORMAT_R32G32B32A32_UINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32B32A32_SINT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
| ename:VK_FORMAT_R32G32B32A32_SFLOAT | {sym1} | {sym1} | | {sym1} | | {sym1} | {sym1} | | | {sym1} | {sym1} | {sym1} |
|====
<<<
[[formats-mandatory-features-64bit]]
.Mandatory format support: 64-bit/uneven channels
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_R64_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64_SFLOAT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64_SFLOAT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64_SFLOAT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64A64_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64A64_SINT | | | | | | | | | | | | |
| ename:VK_FORMAT_R64G64B64A64_SFLOAT | | | | | | | | | | | | |
| ename:VK_FORMAT_B10G11R11_UFLOAT_PACK32 | {sym1} | {sym1} | {sym1} | | | | | | | | {sym1} | |
| ename:VK_FORMAT_E5B9G9R9_UFLOAT_PACK32 | {sym1} | {sym1} | {sym1} | | | | | | | | | |
|====
<<<
[[formats-mandatory-features-depth-stencil]]
.Mandatory format support: depth/stencil with elink:VkImageType ename:VK_IMAGE_TYPE_2D
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_D16_UNORM | {sym1} | {sym1} | | | | | | | {sym1} | | | |
| ename:VK_FORMAT_X8_D24_UNORM_PACK32 | | | | | | | | | {sym2} | | | |
| ename:VK_FORMAT_D32_SFLOAT | {sym1} | {sym1} | | | | | | | {sym2} | | | |
| ename:VK_FORMAT_S8_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_D16_UNORM_S8_UINT | | | | | | | | | | | | |
| ename:VK_FORMAT_D24_UNORM_S8_UINT | | | | | | | | | {sym2} | | | |
| ename:VK_FORMAT_D32_SFLOAT_S8_UINT | | | | | | | | | {sym2} | | | |
14+| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT feature must: be
supported for at least one of ename:VK_FORMAT_X8_D24_UNORM_PACK32 and
ename:VK_FORMAT_D32_SFLOAT, and must: be supported for at least one of
ename:VK_FORMAT_D24_UNORM_S8_UINT and ename:VK_FORMAT_D32_SFLOAT_S8_UINT.
|====
<<<
[[formats-mandatory-features-bcn]]
.Mandatory format support: BC compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D and ename:VK_IMAGE_TYPE_3D
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_BC1_RGB_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC1_RGB_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC1_RGBA_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC1_RGBA_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC2_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC2_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC3_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC3_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC4_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC4_SNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC5_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC5_SNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC6H_UFLOAT_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC6H_SFLOAT_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC7_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_BC7_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
14+| The ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT,
ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT and
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT features must: be
supported in pname:optimalTilingFeatures for all the formats in at least
one of: this table, <<formats-mandatory-features-etc>>, or
<<formats-mandatory-features-astc>>.
|====
<<<
[[formats-mandatory-features-etc]]
.Mandatory format support: ETC2 and EAC compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_EAC_R11_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_EAC_R11_SNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_EAC_R11G11_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_EAC_R11G11_SNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
14+|The ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT,
ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT and
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT features must: be
supported in pname:optimalTilingFeatures for all the formats in at least
one of: this table, <<formats-mandatory-features-bcn>>, or
<<formats-mandatory-features-astc>>.
|====
<<<
[[formats-mandatory-features-astc]]
.Mandatory format support: ASTC LDR compressed formats with elink:VkImageType ename:VK_IMAGE_TYPE_2D
[width="100%",cols="12,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
13+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_ATOMIC_BIT .14+^.^| {downarrow}
12+>| ename:VK_FORMAT_FEATURE_STORAGE_TEXEL_BUFFER_BIT .13+^.^| {downarrow}
11+>| ename:VK_FORMAT_FEATURE_UNIFORM_TEXEL_BUFFER_BIT .12+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_VERTEX_BUFFER_BIT .11+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT .10+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT .9+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_BLIT_DST_BIT .8+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BIT .7+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_ATOMIC_BIT .6+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_STORAGE_IMAGE_BIT .5+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT .4+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT .3+^.^| {downarrow}
1+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .2+^.^| {downarrow}
s| Format
| ename:VK_FORMAT_ASTC_4x4_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_4x4_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_5x4_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_5x4_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_5x5_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_5x5_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_6x5_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_6x5_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_6x6_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_6x6_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x5_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x5_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x6_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x6_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x8_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_8x8_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x5_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x5_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x6_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x6_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x8_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x8_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x10_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_10x10_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_12x10_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_12x10_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_12x12_UNORM_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
| ename:VK_FORMAT_ASTC_12x12_SRGB_BLOCK | {sym2} | {sym2} | {sym2} | | | | | | | | | |
14+|The ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT,
ename:VK_FORMAT_FEATURE_BLIT_SRC_BIT and
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_LINEAR_BIT features must: be
supported in pname:optimalTilingFeatures for all the formats in at least
one of: this table, <<formats-mandatory-features-bcn>>, or
<<formats-mandatory-features-etc>>.
|====
ifdef::VK_IMG_filter_cubic,VK_EXT_filter_cubic[]
If cubic filtering is supported,
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT must: be
supported for the following image view types:
* ename:VK_IMAGE_VIEW_TYPE_1D
* ename:VK_IMAGE_VIEW_TYPE_1D_ARRAY
* ename:VK_IMAGE_VIEW_TYPE_2D
* ename:VK_IMAGE_VIEW_TYPE_2D_ARRAY
for the following formats:
* ename:VK_FORMAT_R4G4_UNORM_PACK8
* ename:VK_FORMAT_R4G4B4A4_UNORM_PACK16
* ename:VK_FORMAT_B4G4R4A4_UNORM_PACK16
* ename:VK_FORMAT_R5G6B5_UNORM_PACK16
* ename:VK_FORMAT_B5G6R5_UNORM_PACK16
* ename:VK_FORMAT_R5G5B5A1_UNORM_PACK16
* ename:VK_FORMAT_B5G5R5A1_UNORM_PACK16
* ename:VK_FORMAT_A1R5G5B5_UNORM_PACK16
* ename:VK_FORMAT_R8_UNORM
* ename:VK_FORMAT_R8_SNORM
* ename:VK_FORMAT_R8_SRGB
* ename:VK_FORMAT_R8G8_UNORM
* ename:VK_FORMAT_R8G8_SNORM
* ename:VK_FORMAT_R8G8_SRGB
* ename:VK_FORMAT_R8G8B8_UNORM
* ename:VK_FORMAT_R8G8B8_SNORM
* ename:VK_FORMAT_R8G8B8_SRGB
* ename:VK_FORMAT_B8G8R8_UNORM
* ename:VK_FORMAT_B8G8R8_SNORM
* ename:VK_FORMAT_B8G8R8_SRGB
* ename:VK_FORMAT_R8G8B8A8_UNORM
* ename:VK_FORMAT_R8G8B8A8_SNORM
* ename:VK_FORMAT_R8G8B8A8_SRGB
* ename:VK_FORMAT_B8G8R8A8_UNORM
* ename:VK_FORMAT_B8G8R8A8_SNORM
* ename:VK_FORMAT_B8G8R8A8_SRGB
* ename:VK_FORMAT_A8B8G8R8_UNORM_PACK32
* ename:VK_FORMAT_A8B8G8R8_SNORM_PACK32
* ename:VK_FORMAT_A8B8G8R8_USCALED_PACK32
* ename:VK_FORMAT_A8B8G8R8_SSCALED_PACK32
* ename:VK_FORMAT_A8B8G8R8_UINT_PACK32
* ename:VK_FORMAT_A8B8G8R8_SINT_PACK32
* ename:VK_FORMAT_A8B8G8R8_SRGB_PACK32
If ETC compressed formats are supported,
ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_FILTER_CUBIC_BIT_EXT must: be
supported for the following image view types:
* ename:VK_IMAGE_VIEW_TYPE_2D
* ename:VK_IMAGE_VIEW_TYPE_2D_ARRAY
for the following additional formats:
* ename:VK_FORMAT_ETC2_R8G8B8_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8_SRGB_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A1_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A1_SRGB_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK
* ename:VK_FORMAT_ETC2_R8G8B8A8_SRGB_BLOCK
If cubic filtering is supported for any other uncompressed formats, the
following image view types must: be supported for those formats:
* ename:VK_IMAGE_VIEW_TYPE_1D
* ename:VK_IMAGE_VIEW_TYPE_1D_ARRAY
* ename:VK_IMAGE_VIEW_TYPE_2D
* ename:VK_IMAGE_VIEW_TYPE_2D_ARRAY
If cubic filtering is supported for any other compressed formats, the
following image view types must: be supported for those formats:
* ename:VK_IMAGE_VIEW_TYPE_2D
* ename:VK_IMAGE_VIEW_TYPE_2D_ARRAY
endif::VK_IMG_filter_cubic,VK_EXT_filter_cubic[]
ifdef::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
To be used with sname:VkImageView with pname:subresourceRange.aspectMask =
ename:VK_IMAGE_ASPECT_COLOR_BIT, <<samplers-YCbCr-conversion,sampler
Y'C~B~C~R~ conversion>> must: be enabled for the following formats:
[[formats-requiring-sampler-ycbcr-conversion]]
.Formats requiring sampler Y'C~B~C~R~ conversion for ename:VK_IMAGE_ASPECT_COLOR_BIT image views
[width="100%",cols="18,^3,^1,^1,^1,^1,^1,^1,^1,^1,^1,^1",options="unbreakable"]
|====
11+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_FORCEABLE_BIT .11+^.^| {downarrow}
10+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_CHROMA_RECONSTRUCTION_EXPLICIT_BIT .10+^.^| {downarrow}
9+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_SEPARATE_RECONSTRUCTION_FILTER_BIT .9+^.^| {downarrow}
8+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_YCBCR_CONVERSION_LINEAR_FILTER_BIT .8+^.^| {downarrow}
7+>| ename:VK_FORMAT_FEATURE_MIDPOINT_CHROMA_SAMPLES_BIT .7+^.^| {downarrow}
6+>| ename:VK_FORMAT_FEATURE_COSITED_CHROMA_SAMPLES_BIT .6+^.^| {downarrow}
5+>| ename:VK_FORMAT_FEATURE_TRANSFER_DST_BIT .5+^.^| {downarrow}
4+>| ename:VK_FORMAT_FEATURE_TRANSFER_SRC_BIT .4+^.^| {downarrow}
3+>| ename:VK_FORMAT_FEATURE_SAMPLED_IMAGE_BIT .3+^.^| {downarrow}
2+>| ename:VK_FORMAT_FEATURE_DISJOINT_BIT .2+^.^| {downarrow}
s| Format s| Planes
| ename:VK_FORMAT_G8B8G8R8_422_UNORM | 1 | | | | | | | | | |
| ename:VK_FORMAT_B8G8R8G8_422_UNORM | 1 | | | | | | | | | |
| ename:VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM | 3 | | {sym1} | {sym1} | {sym1} | {sym1} | | | | |
| ename:VK_FORMAT_G8_B8R8_2PLANE_420_UNORM | 2 | | {sym1} | {sym1} | {sym1} | {sym1} | | | | |
| ename:VK_FORMAT_G8_B8_R8_3PLANE_422_UNORM | 3 | | | | | | | | | |
| ename:VK_FORMAT_G8_B8R8_2PLANE_422_UNORM | 2 | | | | | | | | | |
| ename:VK_FORMAT_G8_B8_R8_3PLANE_444_UNORM | 3 | | | | | | | | | |
| ename:VK_FORMAT_R10X6G10X6B10X6A10X6_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_G10X6B10X6G10X6R10X6_422_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_B10X6G10X6R10X6G10X6_422_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_420_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_420_UNORM_3PACK16 | 2 | | | | | | | | | |
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_422_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_G10X6_B10X6R10X6_2PLANE_422_UNORM_3PACK16 | 2 | | | | | | | | | |
| ename:VK_FORMAT_G10X6_B10X6_R10X6_3PLANE_444_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_R12X4G12X4B12X4A12X4_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_G12X4B12X4G12X4R12X4_422_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_B12X4G12X4R12X4G12X4_422_UNORM_4PACK16 | 1 | | | | | | | | | |
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_420_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_420_UNORM_3PACK16 | 2 | | | | | | | | | |
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_422_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_G12X4_B12X4R12X4_2PLANE_422_UNORM_3PACK16 | 2 | | | | | | | | | |
| ename:VK_FORMAT_G12X4_B12X4_R12X4_3PLANE_444_UNORM_3PACK16 | 3 | | | | | | | | | |
| ename:VK_FORMAT_G16B16G16R16_422_UNORM | 1 | | | | | | | | | |
| ename:VK_FORMAT_B16G16R16G16_422_UNORM | 1 | | | | | | | | | |
| ename:VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM | 3 | | | | | | | | | |
| ename:VK_FORMAT_G16_B16R16_2PLANE_420_UNORM | 2 | | | | | | | | | |
| ename:VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM | 3 | | | | | | | | | |
| ename:VK_FORMAT_G16_B16R16_2PLANE_422_UNORM | 2 | | | | | | | | | |
| ename:VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM | 3 | | | | | | | | | |
12+| Format features marked {sym1} must: be supported only if slink:VkPhysicalDeviceSamplerYcbcrConversionFeatures is enabled,
and only with elink:VkImageType ename:VK_IMAGE_TYPE_2D
|====
Implementations are not required to support the
ename:VK_IMAGE_CREATE_SPARSE_BINDING_BIT,
ename:VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT, or
ename:VK_IMAGE_CREATE_SPARSE_ALIASED_BIT tlink:VkImageCreateFlags for the
above formats that require <<samplers-YCbCr-conversion,sampler Y'C~B~C~R~
conversion>>.
To determine whether the implementation supports sparse image creation flags
with these formats use flink:vkGetPhysicalDeviceImageFormatProperties or
flink:vkGetPhysicalDeviceImageFormatProperties2.
endif::VK_VERSION_1_1,VK_KHR_sampler_ycbcr_conversion[]
ifdef::VK_EXT_fragment_density_map[]
ename:VK_FORMAT_FEATURE_FRAGMENT_DENSITY_MAP_BIT_EXT must: be supported for
the following formats if the <<features-fragmentdensitymap,fragment density
map feature>> is enabled:
* ename:VK_FORMAT_R8G8_UNORM
endif::VK_EXT_fragment_density_map[]