8. Extension for more complex formats

Some formats will require more channels than can be described in the Basic Format Descriptor, or may have more specific color requirements. For example, it is expected than an extension will be available which places an ICC color profile block into the descriptor block, allowing more color channels to be specified in more precise ways. This will significantly enlarge the space required for the descriptor, and is not expected to be needed for most common uses. A vendor may also use an extension block to associate metadata with the descriptor — for example, information required as part of hardware rendering. So long as software which uses the data format descriptor always uses the total_size field to determine the size of the descriptor, this should be transparent to user code.

The extension mechanism is the preferred way to support even simple extensions such as additional color spaces transfer functions that can be supported by an additional enumeration. This approach improves compatibility with code which is unaware of the additional values. Simple extensions of this form that have cross-vendor support have a good chance of being incorporated more directly into future revisions of the specification, allowing application code to distinguish them by the version_id field.

As an example, consider a single-channel 32-bit depth buffer. A tiled renderer may wish to indicate that this buffer is “virtual”: it will be allocated real memory only if needed, and will otherwise exist only a subset at a time in an on-chip representation. Someone developing such a renderer may choose to add a vendor-specific extension (with ID 0xFFFF to indicate development work and avoid the need for a vendor ID) which uses a boolean to establish whether this depth buffer exists only in virtual form. Note that the mere presence or absence of this extension within the data format descriptor itself forms a boolean, but for this example we will assume that an extension block is always present, and that a boolean is stored within. We will give the enumeration 32 bits, in order to simplify the possible addition of further extensions.

In this example (which should not be taken as an implementation suggestion), the data descriptor would first contain a descriptor block describing the depth buffer format as conventionally described, followed by a second descriptor block that contains only the enumeration. The descriptor itself has a total_size that includes both of these descriptor blocks.

Table 25. Example of a depth buffer with an extension to indicate a virtual allocation

56 (total_size: total size of the two blocks plus one 32-bit value)

Basic descriptor block

0 (vendor_id)

0 (descriptor_type)

0 (version_number)

40 (descriptor_block_size)

RGBSDA (color_model)

UNSPECIFIED (color_primaries)

UNSPECIFIED (transfer_function)

0 (flags)

0 (texel_block_dimension_0)

0 (texel_block_dimension_1)

0 (texel_block_dimension_2)

0 (texel_block_dimension_3)

4 (bytes_plane_0)

0 (bytes_plane_1)

0 (bytes_plane_2)

0 (bytes_plane_3)

0 (bytes_plane_4)

0 (bytes_plane_5)

0 (bytes_plane_6)

0 (bytes_plane_7)

Sample information for the depth value

0 (bit_offset)

32 (bit_length)

SIGNED | FLOAT | DEPTH

0 (sample_position_0)

0 (sample_position_1)

0 (sample_position_2)

0 (sample_position_3)

0xbf800000 (sample_lower: -1.0f)

0x3f800000U (sample_upper: 1.0f)

Extension descriptor block

0xFFFF (vendor_id)

0 (descriptor_type)

0 (version_number)

12 (descriptor_block_size)

Data specific to the extension follows

1 (buffer is “virtual”)


It is possible for a vendor to use the extension block to store peripheral information required to access the image — plane base addresses, stride, etc. Since different implementations have different kinds of nonlinear ordering and proprietary alignment requirements, this is not described as part of the standard. By many conventional definitions, this information is not part of the “format”, and particularly it ensures that an identical copy of the image will have a different descriptor block (because the addresses will have changed) and so a simple bitwise comparison of two descriptor blocks will disagree even though the “format” matches. Additionally, many APIs will use the format descriptor only for external communication, and have an internal representation that is more concise and less flexible. In this case, it is likely that address information will need to be represented separately from the format anyway. For these reasons, it is an implementation choice whether to store this information in an extension block, and how to do so, rather than being specified in this standard..