Module vulkano::format[−][src]

Expand description

All the formats supported by Vulkan.

A format is mostly used to describe the texel data of an image. However, formats also show up in a few other places, most notably to describe the format of vertex buffers.

Format support

Not all formats are supported by every device. Those that devices do support may only be supported for certain use cases. It is an error to use a format where it is not supported, but you can query a device beforehand for its support by calling the properties method on a format value. You can use this to select a usable format from one or more suitable alternatives. Some formats are required to be always supported for a particular usage. These are listed in the tables in the Vulkan specification.

Special format types

Depth/stencil formats

Depth/stencil formats can be identified by the D and S components in their names. They are used primarily as the format for framebuffer attachments, for the purposes of depth and stencil testing.

Some formats have only a depth or stencil component, while others combine both. The two components are represented as separate aspects, which means that they can be accessed individually as separate images. These pseudo-images have the same resolution, but different bit depth and numeric representation.

Depth/stencil formats deviate from the others in a few more ways. Their data representation is considered opaque, meaning that they do not have a fixed layout in memory nor a fixed size per texel. They also have special limitations in several operations such as copying; a depth/stencil format is not compatible with any other format, only with itself.

Block-compressed formats

A block-compressed format uses compression to encode a larger block of texels into a smaller number of bytes. Individual texels are no longer represented in memory, only the block as a whole. An image must consist of a whole number of blocks, so the dimensions of an image must be a whole multiple of the block dimensions. Vulkan supports several different compression schemes, represented in Vulkano by the CompressionType enum.

Overall, block-compressed formats do not behave significantly differently from regular formats. They are mostly restricted in terms of compatibility. Because of the compression, the notion of bits per component does not apply, so the components method will only return whether a component is present or not.

YCbCr formats

YCbCr, also known as YUV, is an alternative image representation with three components: Y for luminance or luma (overall brightness) and two color or chroma components Cb and Cr encoding the blueness and redness respectively. YCbCr formats are primarily used in video applications. In Vulkan, the formats used to encode YCbCr data use the green channel to represent the luma component, while the blue and red components hold the chroma.

To use most YCbCr formats in an image view, a feature known as sampler YCbCr conversion is needed. It must be enabled on both the image view and any combined image samplers in shaders that the image view is attached to. This feature handles the correct conversion between YCbCr input data and RGB data inside the shader. To query whether a format requires the conversion, you can call requires_sampler_ycbcr_conversion on a format. As a rule, any format with 444, 422, 420, 3PACK or 4PACK in the name requires it.

Almost all YCbCr formats make use of chroma subsampling. This is a technique whereby the two chroma components are encoded using a lower resolution than the luma component. The human eye is less sensitive to color detail than to detail in brightness, so this allows more detail to be encoded in less data. Chroma subsampling is indicated with one of three numbered suffixes in a format name:

444 indicates a YCbCr format without chroma subsampling. All components have the same resolution.
422 indicates horizontal chroma subsampling. The horizontal resolution of the chroma components is halved, so a single value is shared within a 2x1 block of texels.
420 indicates horizontal and vertical chroma subsampling. Both dimensions of the chroma components are halved, so a single value is shared within a 2x2 block of texels.

Most YCbCr formats, including all of the 444 and 420 formats, are multi-planar. Instead of storing the components of a single texel together in memory, the components are separated into planes, which act like independent images. In 3-plane formats, the planes hold the Y, Cb and Cr components respectively, while in 2-plane formats, Cb and Cr are combined into a two-component plane. Where chroma subsampling is applied, plane 0 has the full resolution, while planes 1 and 2 have reduced resolution. Effectively, they are standalone images with half the resolution of the original.

The texels of multi-planar images cannot be accessed individually, for example to copy or blit, since the components of each texel are split across the planes. Instead, you must access each plane as an individual aspect of the image. A single-plane aspect of a multi-planar image behaves as a regular image, and even has its own format, which can be queried with the plane method on a format.