Google is committed to advancing racial equity for Black communities. See how.

fuchsia.sysmem2

PROTOCOLS

Heap

Defined in fuchsia.sysmem2/heap.fidl

Manages resources on a specific sysmem heap.

AllocateVmo

Request a new memory allocation of size on heap. For heaps which don't permit CPU access to the buffer data, this will create a VMO with an official size, but which never has any physical pages. For such heaps, the VMO is effectively used as an opaque buffer identifier.

Heaps should defer allocation of any associated resources until CreateResource(), because the caller of AllocateVmo() may simply delete the returned VMO with no further notification to the heap. In contrast, after CreateResource(), the caller guarantees that DestroyResource() or heap channel closure will occur.

The caller guarantees that CreateResource() will be called prior to the returned VMO or any associated child VMO being used.

Request

NameType
size uint64

Response

NameType
s zx/status
vmo handle<vmo>?

CreateResource

Create resources and associate heap-specific resources with the passed-in VMO. Resources can be hardware specific and their lifetime don't have to be tied to vmo. vmo must be a VMO (or a direct or indirect child of a VMO) acquired through a call to AllocateVmo method above. If the passed-in vmo is a child VMO, its size must match the size of the parent VMO created by AllocateVmo(). For heaps that permit CPU access, the passed-in VMO must not have a copy-on-write relationship with the parent VMO, but rather a pass-through relationship. Successful return status indicate that Heap has established a mapping between VMO and hardware specific resources.

The returned id must be passed to DestroyResource() later when resources associated with VMO are no longer needed, unless the heap channel closes first.

The heap must not own/keep a handle to VMO, or any derived child VMO, or any VMAR mapping to VMO, as any of those would keep VMO alive beyond all sysmem participant usages of the vmo; instead the heap can get the vmo's koid for the heap's mapping.

Request

NameType
vmo handle<vmo>
buffer_settings SingleBufferSettings

Response

NameType
s zx/status
id uint64

DestroyResource

Destroy previously created resources.

Request

NameType
id uint64

Response

NameType

OnRegister

This event is triggered when the Heap is registered. Properties of this Heap will be sent to the sysmem device in the event.

Implementations should guarantee that this event should be sent immediately when it binds to a channel, and this event should be triggered only once per Heap instance.

Response

NameType
properties HeapProperties

STRUCTS

ENUMS

CoherencyDomain

Type: uint32

Defined in fuchsia.sysmem2/constraints.fidl

Inaccessible is only for cases where there is no CPU-based access to the buffers. A secure_required buffer can still have CoherencyDomain Cpu or Ram even if the secure_required buffer can only be accessed by the CPU when the CPU is running in secure mode (or similar). In contrast, device-local memory that isn't reachable from the CPU is CoherencyDomain Inaccessible, even if it's possible to cause a device (physical or virtual) to copy the data from the Inaccessible buffers to buffers that are visible to the CPU.

NameValueDescription
CPU 0
RAM 1
INACCESSIBLE 2

ColorSpaceType

Type: uint32

Defined in fuchsia.sysmem2/image_formats.fidl

This list has a separate entry for each variant of a color space standard.

For this reason, should we ever add support for the RGB variant of 709, for example, we'd add a separate entry to this list for that variant. Similarly for the RGB variants of 2020 or 2100. Similarly for the YcCbcCrc variant of 2020. Similarly for the ICtCp variant of 2100.

A given ColorSpaceType may permit usage with a PixelFormatType(s) that provides a bits-per-sample that's compatible with the ColorSpaceType's official spec. Not all spec-valid combinations are necessarily supported. See ImageFormatIsSupportedColorSpaceForPixelFormat() for the best-case degree of support, but a "true" from that function doesn't guarantee that any given combination of participants will all support the desired combination of ColorSpaceType and PixelFormatType.

The sysmem service helps find a mutually supported combination and allocate suitable buffers.

A ColorSpaceType's spec is not implicitly extended to support outside-the-standard bits-per-sample (R, G, B, or Y sample). For example, for 2020 and 2100, 8 bits-per-Y-sample is not supported (by sysmem), because 8 bits-per-Y-sample is not in the spec for 2020 or 2100. A sysmem participant that attempts to advertise support for a PixelFormat + ColorSpace that's non-standard will cause sysmem to reject the combo and fail to allocate (intentionally, to strongly discourage specifying insufficiently-defined combos).

NameValueDescription
INVALID 0

Not a valid color space type.

SRGB 1

sRGB

REC601_NTSC 2

601 NTSC ("525 line") YCbCr primaries, narrow

REC601_NTSC_FULL_RANGE 3

601 NTSC ("525 line") YCbCr primaries, wide

REC601_PAL 4

601 PAL ("625 line") YCbCr primaries, narrow

REC601_PAL_FULL_RANGE 5

601 PAL ("625 line") YCbCr primaries, wide

REC709 6

709 YCbCr (not RGB)

REC2020 7

2020 YCbCr (not RGB, not YcCbcCrc)

REC2100 8

2100 YCbCr (not RGB, not ICtCp)

HeapType

Type: uint64

Defined in fuchsia.sysmem2/constraints.fidl

Known heap types. Device specific types should have bit 60 set. Top order bit is reserved and should not be set.

NameValueDescription
SYSTEM_RAM 0
AMLOGIC_SECURE 1152921504606912512

Heap used for amlogic protected memory.

AMLOGIC_SECURE_VDEC 1152921504606912513

Heap used for amlogic protected memory between decrypt and video decode.

GOLDFISH_DEVICE_LOCAL 1152921504606978048

Heap used by goldfish vulkan for device-local memory.

GOLDFISH_HOST_VISIBLE 1152921504606978049

Heap used by goldfish vulkan for host-visible memory.

PixelFormatType

Type: uint32

Defined in fuchsia.sysmem2/image_formats.fidl

The ordering of the channels in the format name reflects the actual layout of the channel.

Each of these values is opinionated re. the color spaces that should be contained within (in contrast with Vulkan).

This should be kept in sync with fuchsia.sysmem.PixelFormatType.

NameValueDescription
INVALID 0
R8G8B8A8 1

RGB only, 8 bits per each of R/G/B/A sample Compatible with VK_FORMAT_R8G8B8A8_UNORM. Compatible with ZX_PIXEL_FORMAT_ABGR_8888 and ZX_PIXEL_FORMAT_BGR_x8888.

BGRA32 101

32bpp BGRA, 1 plane. RGB only, 8 bits per each of B/G/R/A sample. Compatible with VK_FORMAT_B8G8R8A8_UNORM. Compatible with ZX_PIXEL_FORMAT_RGB_x888 and ZX_PIXEL_FORMAT_ARGB_8888.

I420 102

YUV only, 8 bits per Y sample Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM.

M420 103

YUV only, 8 bits per Y sample Not compatible with any vulkan format.

NV12 104

YUV only, 8 bits per Y sample Compatible with VK_FORMAT_G8_B8R8_2PLANE_420_UNORM. Compatible with ZX_PIXEL_FORMAT_NV12.

YUY2 105

YUV only, 8 bits per Y sample Compatible with VK_FORMAT_G8B8G8R8_422_UNORM.

MJPEG 106
YV12 107

YUV only, 8 bits per Y sample Compatible with VK_FORMAT_G8_B8_R8_3PLANE_420_UNORM with B and R swizzled.

BGR24 108

24bpp BGR, 1 plane. RGB only, 8 bits per each of B/G/R sample Compatible with VK_FORMAT_B8G8R8_UNORM. Compatible with ZX_PIXEL_FORMAT_RGB_888.

RGB565 109

16bpp RGB, 1 plane. 5 bits R, 6 bits G, 5 bits B Compatible with VK_FORMAT_R5G6B5_UNORM_PACK16. Compatible with ZX_PIXEL_FORMAT_RGB_565.

RGB332 110

8bpp RGB, 1 plane. 3 bits R, 3 bits G, 2 bits B Not compatible with any vulkan format. Compatible with ZX_PIXEL_FORMAT_RGB_332.

RGB2220 111

8bpp RGB, 1 plane. 2 bits R, 2 bits G, 2 bits B Not compatible with any vulkan format. Compatible with ZX_PIXEL_FORMAT_RGB_2220.

L8 112

8bpp, Luminance-only. Compatible with VK_FORMAT_R8_UNORM. Compatible with ZX_PIXEL_FORMAT_GRAY_8 and ZX_PIXEL_FORMAT_MONO_8.

TABLES

BufferCollectionConstraints

Defined in fuchsia.sysmem2/constraints.fidl

Constraints on BufferCollection parameters. These constraints can be specified per-participant. The sysmem service implements aggregation of constraints from multiple participants.

OrdinalNameTypeDescription
1 usage BufferUsage

The usage is only meant as a hint to help sysmem choose a more optimal PixelFormat or similar when multiple compatible options exist.

When aggregating BufferCollectionConstraints, these values bitwise-OR.

At least one usage bit must be specified unless the whole BufferCollectionConstraints is logically null (no fields set).

2 min_buffer_count_for_camping uint32

Per-participant minimum number of buffers that are needed for camping purposes. A participant should specify a number for min_buffer_count that's >= the maximum number of buffers that the participant may concurrently camp on for any non-transient period of time.

For example, a video decoder would specify (at least) the maximum number of reference frames + 1 frame currently being decoded into.

A participant must not camp on more buffers than specified here (except very transiently) else processing may get stuck.

When aggregating BufferCollectionConstraints, these values add.

In testing scenarios, camping on more buffers than this for any significant duration may (ideally will) be flagged as a failure. In testing scenarios, the participant may not be provided with more buffers than this concurrently.

3 min_buffer_count_for_dedicated_slack uint32

Per-participant minimum number of buffers that are needed for slack reasons, for better overlap of processing / better performance.

When aggregating BufferCollectionConstraints, these values add.

A participant should typically specify 0 or 1 here - typically 0 is appropriate if min_buffer_count_for_camping is already enough to keep the participant busy 100% of the time when the participant is slightly behind, while 1 can be appropriate if 1 more buffer than strictly needed for min-camping reasons gives enough slack to stay busy 100% of the time (when slightly behind, vs. lower % without the extra buffer).

In testing scenarios, this field may be forced to 0, and all participants are expected to continue to work without getting stuck. If a buffer is needed for forward progress reasons, that buffer should be accounted for in min_buffer_count_for_camping.

4 min_buffer_count_for_shared_slack uint32

Similar to min_buffer_count_for_dedicated_slack, except when aggregating these values max (instead of add). The value here is not shared with any participant's min_buffer_count_for_dedicated_slack.

A participant can specify > 0 here if a participant would like to ensure there's some slack overall, but doesn't need that slack to be dedicated.

The choice whether to use min_buffer_count_for_dedicated_slack or min_buffer_count_for_shared_slack (or both) will typically be about the degree to which the extra slack improves performance.

In testing scenarios, this field may be forced to 0, and all participants are expected to continue to work without getting stuck. If a buffer is needed for forward progress reasons, that buffer should be accounted for in min_buffer_count_for_camping.

5 min_buffer_count uint32

A particularly-picky participant may unfortunately need to demand a tight range of buffer_count, or even a specific buffer_count. This field should remain 0 unless a participant really must set this field to constrain the overall BufferCollectionInfo_2.buffer_count. Any such participant should still fill out the min_buffer_count_for_* fields.

If this field is un-set, the logical min_buffer_count is 1.

6 max_buffer_count uint32

A particularly-picky participant may unfortunately need to demand a tight range of buffer_count, or even a specific buffer_count. This field should remain 0 unless a participant really must set this field to constrain the overall BufferCollectionInfo_2.buffer_count. Any such participant should still fill out the min_buffer_count_for_* fields.

If this field is un-set, the logical max_buffer_count is 0xFFFFFFFF.

7 buffer_memory_constraints BufferMemoryConstraints

Optional constraints on BufferCollectionSettings.buffer_settings.

A participant that intends to specify image_format_constraints_count > 1 will typically specify the minimum buffer size implicitly via image_format_constraints, and possibly specify only the max buffer size via buffer_memory_constraints.

If un-set, the client is specifying "don't care" re. any buffer memory constraints.

8 image_format_constraints vector<ImageFormatConstraints>[64]

Optional constraints on the image format parameters of an image stored in a buffer of the BufferCollection. This includes pixel format and image layout. These constraints are per-pixel-format, so more than one is permitted.

When aggregating, only pixel formats that are specified by all particpants with non-zero image_format_constraints_count (and non-Null) BufferCollectionConstraints) are retained.

un-set means no image format constraints. set but zero length is an error.

9 need_clear_aux_buffers_for_secure bool

If true, a secure heap may only be selected if all participants with BufferMemoryConstraints specify allow_clear_aux_buffers_for_secure. If "need" is true, "allow" must also be true.

If false (or unset), the participant can still work, potentially even with secure memory (depending on supported heaps), without clear aux buffers.

10 allow_clear_aux_buffers_for_secure bool

If true, the participant will use clear aux buffers, if they are allocated, as appropriate to the participant's role. If the participant is a writer, then the participant writer will populate the clear aux buffers with the clear (not-encrypted, not-DRM-protected) bytes, and fill protected bytes with data that does not emulate start codes, such as 0xFF.

If un-set, then allow_clear_aux_buffers_for_secure is true iff the participant specifies usage which is read-only.

If un-set from a participant with write usage, or false, the buffer collection won't be able to allocate if any participant specifies need_clear_aux_buffers_for_secure true.

BufferCollectionInfo

Defined in fuchsia.sysmem2/results.fidl

Information about a buffer collection and its buffers.

OrdinalNameTypeDescription
1 settings SingleBufferSettings

These settings apply to all the buffers in the inital buffer allocation. This must be set.

2 buffers vector<VmoBuffer>[128]

VMO handles (and vmo_usable_start offset) for each buffer in the collection.

The size of this vector is the buffer_count (buffer_count is not sent separately).

All buffer VMO handles have identical size and access rights. The size is in settings.buffer_settings.size_bytes.

The VMO access rights are determined based on the usages which the client specified when allocating the buffer collection. For example, a client which expressed a read-only usage will receive VMOs without write rights. In addition, the rights can be attenuated by the parameter to BufferCollectionToken.Duplicate() calls.

This field will always have VmoBuffer(s) in it, even if the participant specifies usage whieh does not require VMO handles. This permits such a participant to know the vmo_usable_start values, in case that's of any use to the participant.

BufferMemoryConstraints

Defined in fuchsia.sysmem2/constraints.fidl

OrdinalNameTypeDescription
1 min_size_bytes uint32
2 max_size_bytes uint32

un-set is treated as 0xFFFFFFFF.

3 physically_contiguous_required bool
4 secure_required bool

If true, at least one participant requires secure memory.

When aggregating BufferCollectionConstraints, these values boolean-OR.

5 cpu_domain_supported bool

By default, participants must ensure the CPU can read or write data to the buffer without cache operations. If they support using the RAM domain, data must be available in RAM (with CPU cache state such that the RAM data won't get corrupted by a dirty CPU cache line writing incorrect data to RAM), and a consumer reading using the CPU must invalidate CPU cache before reading (the producer doesn't guarantee zero stale "clean" cache lines)

6 ram_domain_supported bool
7 inaccessible_domain_supported bool
8 heap_permitted vector<HeapType>[64]

Optional heap constraints. Participants that don't care which heap memory is allocated on should leave this field un-set.

BufferMemorySettings

Defined in fuchsia.sysmem2/results.fidl

These are memory-related settings for all buffers of a buffer collection.

OrdinalNameTypeDescription
1 size_bytes uint32
2 is_physically_contiguous bool
3 is_secure bool
4 coherency_domain CoherencyDomain
5 heap HeapType

The specific heap from which buffers are allocated. See above in this file for heap identifier values.

BufferUsage

Defined in fuchsia.sysmem2/usages.fidl

OrdinalNameTypeDescription
1 none uint32
2 cpu uint32
3 vulkan uint32
4 display uint32
5 video uint32

CoherencyDomainSupport

Defined in fuchsia.sysmem2/heap.fidl

Sysmem Heaps can have different support for different coherency domains. This table contains the support status for each coherency domain of a Heap.

Each member property should correspond to a coherency domain defined in the CoherencyDomain enum.

OrdinalNameTypeDescription
1 cpu_supported bool
2 ram_supported bool
3 inaccessible_supported bool

ColorSpace

Defined in fuchsia.sysmem2/image_formats.fidl

Describes how the pixels within an image are meant to be presented. Simple color spaces need only a type. Parametric color spaces may require additional properties.

OrdinalNameTypeDescription
1 type ColorSpaceType

HeapProperties

Defined in fuchsia.sysmem2/heap.fidl

Memory properties for a sysmem Heap. Heaps send its properties to sysmem device at registration time based on which sysmem can select the correct Heap to use.

OrdinalNameTypeDescription
1 coherency_domain_support CoherencyDomainSupport

Status of support for coherency domains.

2 need_clear bool

Indicates whether sysmem needs to clear VMOs allocated by the Heap.

ImageFormat

Defined in fuchsia.sysmem2/constraints.fidl

Describes how an image is represented.

OrdinalNameTypeDescription
1 pixel_format PixelFormat

Pixel format.

2 coded_width uint32

Row width in pixels that exist in the buffer. Must be >= display_width. Can be < the width implied by stride_bytes.

3 coded_height uint32

Number of rows. Must be >= display_height.

4 bytes_per_row uint32
5 display_width uint32

Row width in pixels that are to be displayed. This can be <= coded_width. Any cropping occurs on the right of the image (not left).

6 display_height uint32

Number of rows to be displayed. This can be <= coded_height, with any cropping on the bottom (not top).

7 color_space ColorSpace

Color space.

8 pixel_aspect_ratio_width uint32

The pixel_aspect_ratio_width : pixel_aspect_ratio_height is the pixel aspect ratio (AKA sample aspect ratio aka SAR) for the luma (AKA Y) samples. A pixel_aspect_ratio of 1:1 mean square pixels. A pixel_aspect_ratio of 2:1 would mean pixels that are displayed twice as wide as they are tall. Codec implementation should ensure these two values are relatively prime by reducing the fraction (dividing both by GCF) if necessary.

A producer should set both these fields, or neither of them.

A consumer should interpret either of these fields being un-set as an unknown pixel_aspect_ratio. A default of 1:1 can be appropriate in some cases, but a consumer may determine the actual pixel_aspect_ratio by OOB means.

9 pixel_aspect_ratio_height uint32

ImageFormatConstraints

Defined in fuchsia.sysmem2/constraints.fidl

Describes constraints on layout of image data in buffers.

OrdinalNameTypeDescription
1 pixel_format PixelFormat

The PixelFormat for which the following constraints apply. A participant may have more than one PixelFormat that's supported, in which case that participant can use a list of ImageFormatConstraints with an entry per PixelFormat. It's not uncommon for the other fields of ImageFormatConstraints to vary by PixelFormat - for example for a linear format to support smaller max size than a tiled format.

2 color_spaces vector<ColorSpace>[32]

Empty is an error. Redundant entries are an error. Arbitrary ordering is not an error.

3 min_coded_width uint32

Minimum permitted width in pixels.

For example a video decoder participant may set this field to the minimum coded_width that might potentially be specified by a stream. In contrast, required_min_coded_width would be set to the current coded_width specified by the stream. While min_coded_width aggregates by taking the max, required_min_coded_width aggregates by taking the min.

See also required_min_coded_width.

4 max_coded_width uint32

Maximum width in pixels. For example Scenic may set this field (directly or via sub-participants) to the maximum width that can be composited. un-set is treated as 0xFFFFFFFF.

5 min_coded_height uint32

Minimum height in pixels. For example a video decoder participant may set this field to the coded_height specified by a stream.

6 max_coded_height uint32

Maximum height in pixels. For example Scenic may set this field (directly or via sub-participants) to the maximum height that can be composited. un-set is treated as 0xFFFFFFFF.

7 min_bytes_per_row uint32

Must be >= the value implied by min_coded_width for plane 0.

8 max_bytes_per_row uint32

Must be >= the value implied by max_coded_width for plane 0. un-set is treated as 0xFFFFFFFF.

9 max_coded_width_times_coded_height uint32

The max image area in pixels is limited indirectly via BufferSettings.size_bytes, and can also be enforced directly via this field. un-set is treated as 0xFFFFFFFF.

10 coded_width_divisor uint32

coded_width % width_divisor must be 0. un-set is treated as 1.

11 coded_height_divisor uint32

coded_height % height_divisor must be 0. un-set is treated as 1.

12 bytes_per_row_divisor uint32

bytes_per_row % bytes_per_row_divisor must be 0. un-set is treated as 1.

13 start_offset_divisor uint32

vmo_usable_start % start_offset_divisor must be 0. un-set is treated as 1.

14 display_width_divisor uint32

display_width % display_width_divisor must be 0. un-set is treated as 1.

15 display_height_divisor uint32

display_height % display_height_divisor must be 0. un-set is treated as 1.

16 required_min_coded_width uint32

required_ dimension bounds.

In contrast to the corresponding fields without "required_" at the start, these fields (when set to non-zero values) express a requirement that the resulting aggregated non-required_ fields specify a space that fully contain the space expressed by each participant's required_ fields.

For example, a producer video decoder is perfectly happy for the consumer to be willing to accept anything, and the video decoder doesn't really want to constrain the potential space of dimensions that might be seen in a stream and may be acceptable to the consumer, but the video decoder needs to ensure that the resulting dimension ranges contain at least the current dimensions decoded from the stream.

Similarly, an initiator with a particular dynamic-dimension scenario in mind may wish to require up front that participants agree to handle at least the range of dimensions expected by the initiator in that scenario (else fail earlier rather than later, maybe trying again with smaller required_ space).

It's much more common for a producer or initiator to set these fields than for a consumer to set these fields.

While the non-required_ fields aggregate by taking the intersection, the required_ fields aggregate by taking the union.

If set, the required_max_coded_width and required_max_coded_height will cause the allocated buffers to be large enough to hold an image that is required_max_coded_width * required_max_coded_height.

TODO(fxbug.dev/34192): Make it easier to allocate buffers of minimal size that can (optionally) also handle 90 degree rotated version of the max dimensions / alternate required bounds for another main aspect ratio. un-set is treated as 0xFFFFFFFF.

17 required_max_coded_width uint32
18 required_min_coded_height uint32

un-set is treated as 0xFFFFFFFF.

19 required_max_coded_height uint32
20 required_min_bytes_per_row uint32

un-set is treated as 0xFFFFFFFF.

21 required_max_bytes_per_row uint32

PixelFormat

Defined in fuchsia.sysmem2/image_formats.fidl

Describes how the pixels within an image are represented. Simple formats need only a type. Parametric pixel formats may require additional properties - any such properties are encoded within the format_modifier_value (for compatibility reasons).

OrdinalNameTypeDescription
1 type PixelFormatType
2 format_modifier_value uint64

The upper 8 bits are a vendor code. The lower 56 bits are vendor-defined. See format_modifier.fidl for potentially-valid values.

These values can be valid values for the |format_modifier_value| field.

The values are defined this way for compatibility reasons.

un-set and 0 both mean there is no format modifier.

SingleBufferSettings

Defined in fuchsia.sysmem2/results.fidl

These settings and constraints apply to all the buffers in the collection.

OrdinalNameTypeDescription
1 buffer_settings BufferMemorySettings
2 image_format_constraints ImageFormatConstraints

Buffers holding data that is not uncompressed image data will not have this field set. Buffers holding data that is uncompressed image data may have this field set.

At least for now, changing the PixelFormat requires re-allocating buffers.

If un-set, there are no image format constraints.

VmoBuffer

Defined in fuchsia.sysmem2/results.fidl

OrdinalNameTypeDescription
1 vmo handle<vmo>

The same VMO can be used by more than one CodecBuffer (only of the same buffer_lifetime_ordinal), but each vmo handle must be a separate handle.

|vmo| can be un-set if a participant has no usage which requires a VMO handle.

2 vmo_usable_start uint64

Offset within the VMO of the first usable byte. Must be < the VMO's size in bytes, and leave sufficient room for BufferMemorySettings.size_bytes before the end of the VMO.

3 aux_vmo handle<vmo>

In some cases, we have a physically separate aux buffer that is a logical shadow of the main buffer. The main use case so far is DRM L1 where we can have a clear aux buffer that has meaningful bytes only for the portions of the input which are clear (not protected). The protected portions will be set to a byte value that will prevent start code emulation (0xFF will work for most video formats).

|aux_vmo| will be un-set if there are no aux buffers, or in the same cases that |vmo| can be un-set.

CONSTANTS

NameValueTypeDescription
CPU_USAGE_READ 1 uint32
CPU_USAGE_READ_OFTEN 2 uint32
CPU_USAGE_WRITE 4 uint32
CPU_USAGE_WRITE_OFTEN 8 uint32
DISPLAY_USAGE_CURSOR 2 uint32
DISPLAY_USAGE_LAYER 1 uint32
FORMAT_MODIFIER_ARM_AFBC_16X16 576460752303423489 uint64
FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV 576460752303423601 uint64
FORMAT_MODIFIER_ARM_AFBC_16X16_SPLIT_BLOCK_SPARSE_YUV_TE 576460752303427697 uint64
FORMAT_MODIFIER_ARM_AFBC_16X16_TE 576460752303427585 uint64
FORMAT_MODIFIER_ARM_AFBC_32X8 576460752303423490 uint64
FORMAT_MODIFIER_ARM_AFBC_32X8_TE 576460752303427586 uint64
FORMAT_MODIFIER_ARM_BCH_BIT 2048 uint64
FORMAT_MODIFIER_ARM_LINEAR_TE 576460752303427584 uint64
FORMAT_MODIFIER_ARM_SPARSE_BIT 64 uint64
FORMAT_MODIFIER_ARM_SPLIT_BLOCK_BIT 32 uint64
FORMAT_MODIFIER_ARM_TE_BIT 4096 uint64
FORMAT_MODIFIER_ARM_YUV_BIT 16 uint64
FORMAT_MODIFIER_INTEL_I915_X_TILED 72057594037927937 uint64
FORMAT_MODIFIER_INTEL_I915_YF_TILED 72057594037927939 uint64
FORMAT_MODIFIER_INTEL_I915_Y_TILED 72057594037927938 uint64
FORMAT_MODIFIER_INVALID FORMAT_MODIFIER_VALUE_RESERVED uint64
FORMAT_MODIFIER_LINEAR 0 uint64
FORMAT_MODIFIER_NONE 0 uint64

The upper 8 bits are a vendor code. The lower 56 bits are vendor-defined. See format_modifier.fidl for potentially-valid values.

These values can be valid values for the |format_modifier_value| field.

The values are defined this way for compatibility reasons.

FORMAT_MODIFIER_VALUE_RESERVED 72057594037927935 uint64
FORMAT_MODIFIER_VENDOR_AMD 144115188075855872 uint64
FORMAT_MODIFIER_VENDOR_ARM 576460752303423488 uint64
FORMAT_MODIFIER_VENDOR_BROADCOM 504403158265495552 uint64
FORMAT_MODIFIER_VENDOR_INTEL 72057594037927936 uint64
FORMAT_MODIFIER_VENDOR_NONE 0 uint64
FORMAT_MODIFIER_VENDOR_NVIDIA 216172782113783808 uint64
FORMAT_MODIFIER_VENDOR_QCOM 360287970189639680 uint64
FORMAT_MODIFIER_VENDOR_SAMSUNG 288230376151711744 uint64
FORMAT_MODIFIER_VENDOR_VIVANTE 432345564227567616 uint64
MAX_COUNT_BUFFER_COLLECTION_CONSTRAINTS_IMAGE_FORMAT_CONSTRAINTS 64 uint32
MAX_COUNT_BUFFER_COLLECTION_INFO_BUFFERS 128 uint32
MAX_COUNT_BUFFER_MEMORY_CONSTRAINTS_HEAP_PERMITTED 64 uint32
MAX_COUNT_IMAGE_FORMAT_CONSTRAINTS_COLOR_SPACES 32 uint32
NONE_USAGE 1 uint32
VIDEO_USAGE_CAPTURE 8 uint32
VIDEO_USAGE_DECRYPTOR_OUTPUT 16 uint32
VIDEO_USAGE_HW_DECODER 1 uint32
VIDEO_USAGE_HW_DECODER_INTERNAL 32 uint32
VIDEO_USAGE_HW_ENCODER 2 uint32
VIDEO_USAGE_HW_PROTECTED 4 uint32
VULKAN_BUFFER_USAGE_INDEX_BUFFER 4194304 uint32
VULKAN_BUFFER_USAGE_INDIRECT_BUFFER 16777216 uint32
VULKAN_BUFFER_USAGE_STORAGE_BUFFER 2097152 uint32
VULKAN_BUFFER_USAGE_STORAGE_TEXEL_BUFFER 524288 uint32
VULKAN_BUFFER_USAGE_TRANSFER_DST 131072 uint32
VULKAN_BUFFER_USAGE_TRANSFER_SRC 65536 uint32
VULKAN_BUFFER_USAGE_UNIFORM_BUFFER 1048576 uint32
VULKAN_BUFFER_USAGE_UNIFORM_TEXEL_BUFFER 262144 uint32
VULKAN_BUFFER_USAGE_VERTEX_BUFFER 8388608 uint32
VULKAN_IMAGE_USAGE_COLOR_ATTACHMENT 16 uint32
VULKAN_IMAGE_USAGE_INPUT_ATTACHMENT 128 uint32
VULKAN_IMAGE_USAGE_SAMPLED 4 uint32
VULKAN_IMAGE_USAGE_STENCIL_ATTACHMENT 32 uint32
VULKAN_IMAGE_USAGE_STORAGE 8 uint32
VULKAN_IMAGE_USAGE_TRANSFER_DST 2 uint32
VULKAN_IMAGE_USAGE_TRANSFER_SRC 1 uint32
VULKAN_IMAGE_USAGE_TRANSIENT_ATTACHMENT 64 uint32
VULKAN_USAGE_COLOR_ATTACHMENT 16 uint32
VULKAN_USAGE_INPUT_ATTACHMENT 128 uint32
VULKAN_USAGE_SAMPLED 4 uint32
VULKAN_USAGE_STENCIL_ATTACHMENT 32 uint32
VULKAN_USAGE_STORAGE 8 uint32
VULKAN_USAGE_TRANSFER_DST 2 uint32
VULKAN_USAGE_TRANSFER_SRC 1 uint32
VULKAN_USAGE_TRANSIENT_ATTACHMENT 64 uint32