pub struct BufferCollectionConstraints {
pub usage: Option<BufferUsage>,
pub min_buffer_count_for_camping: Option<u32>,
pub min_buffer_count_for_dedicated_slack: Option<u32>,
pub min_buffer_count_for_shared_slack: Option<u32>,
pub min_buffer_count: Option<u32>,
pub max_buffer_count: Option<u32>,
pub buffer_memory_constraints: Option<BufferMemoryConstraints>,
pub image_format_constraints: Option<Vec<ImageFormatConstraints>>,
/* private fields */
}
Expand description
Constraints on allocated buffers and, optionally, constraints on images stored in the buffers. These constraints can be specified per-participant. The sysmem service implements aggregation of constraints from multiple participants.
Fields§
§usage: Option<BufferUsage>
The usage
is a hint to sysmem to potentially help choose a more
optimal [fuchsia.images2/PixelFormat
] and/or pixel_format_modifier
when multiple compatible options exist.
When aggregating [fuchsia.sysmem2/BufferCollectionConstraints
], these
values bitwise-OR.
At least one usage
bit must be specified (however, it’s permitted for
a [fuchsia.sysmem2/BufferCollection.SetConstraints
] request to have
the request constraints
field not set, in which case kNoneUsage
is
the default, along with no constraints from the participant).
When kNoneUsage
is specified it must be the only set bit, and no VMOs
will be sent in response to
[fuchsia.sysmem2/BufferCollection.WaitForAllBuffersAllocated
].
min_buffer_count_for_camping: Option<u32>
Per-participant number of buffers that the participant may concurrently hold for its exclusive use for more than a transient duration (camp on). In this context, a “transient” duration is the time it takes to finish running a small amount of non-blocking code that finishes transfering away ownership of the buffer. Things like reading from storage, waiting on hardware that isn’t already known to be done, or doing things like frame encode or decode are not considered transient durations, even if they might sometimes complete quickly.
For example, a video decoder would specify (at least) the maximum number of reference frames + 1 frame currently being decoded into. But not 1 more for the code that runs async and quickly to deliver a previously decoded frame, even though that frame can potentially be owned for a transient duration concurrent with decode of the next frame.
A participant must not camp on more buffers than specified here (except for a transient duration) else processing may get stuck.
When aggregating BufferCollectionConstraints, these values add.
In testing scenarios, camping on more buffers than this for any significant duration (one screen refresh period is “significant” in this context) may (ideally will) be flagged as a failure. In testing scenarios, the participant may not be provided with more buffers than this concurrently.
min_buffer_count_for_dedicated_slack: Option<u32>
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
.
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
.
min_buffer_count: Option<u32>
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.buffer_count
. Any such
participant should still fill out the min_buffer_count_for_* fields as
appropriate.
If this field is un-set, the logical min_buffer_count
is 0.
max_buffer_count: Option<u32>
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.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.
buffer_memory_constraints: Option<BufferMemoryConstraints>
Optional constraints on BufferCollectionSettings.buffer_settings
.
A participant that intends to set image_format_constraints
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.
image_format_constraints: Option<Vec<ImageFormatConstraints>>
Optional constraints on the image format parameters of an image stored
in a buffer of the collection. This includes
[fuchsia.images2/PixelFormat
] and pixel_format_modifier
(for tiling
and the like). These constraints can be specified separately per
pixel_format
pixel_format_modifier
pair. Duplicated pixel_format
pixel_format_modifier
pairs aren’t permitted.
When aggregating, only pixel_format
pixel_format_modifier
pairs that
are specified by all participants with non-zero
image_format_constraints
size (and non-null)
BufferCollectionConstraints) are retained.
A participant can specify pixel_format
[fuchsia.images2/PixelFormat.DO_NOT_CARE
] and/or
pixel_format_modifier
[fuchsia.images2/PixelFormatModifier.DO_NOT_CARE
] to permit any value
to be selected, but at least one participant must specify a specific
format for overall allocation to succeed.
In a SetConstraints message, un-set or zero length means no image format
constraints; a raw buffer can be allocated if no other participants
specify any image_format_constraints
entries.
Trait Implementations§
Source§impl Clone for BufferCollectionConstraints
impl Clone for BufferCollectionConstraints
Source§fn clone(&self) -> BufferCollectionConstraints
fn clone(&self) -> BufferCollectionConstraints
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moreSource§impl Debug for BufferCollectionConstraints
impl Debug for BufferCollectionConstraints
Source§impl<D: ResourceDialect> Decode<BufferCollectionConstraints, D> for BufferCollectionConstraints
impl<D: ResourceDialect> Decode<BufferCollectionConstraints, D> for BufferCollectionConstraints
Source§impl Default for BufferCollectionConstraints
impl Default for BufferCollectionConstraints
Source§fn default() -> BufferCollectionConstraints
fn default() -> BufferCollectionConstraints
Source§impl<D: ResourceDialect> Encode<BufferCollectionConstraints, D> for &BufferCollectionConstraints
impl<D: ResourceDialect> Encode<BufferCollectionConstraints, D> for &BufferCollectionConstraints
Source§impl TypeMarker for BufferCollectionConstraints
impl TypeMarker for BufferCollectionConstraints
Source§type Owned = BufferCollectionConstraints
type Owned = BufferCollectionConstraints
Source§fn inline_align(_context: Context) -> usize
fn inline_align(_context: Context) -> usize
Source§fn inline_size(_context: Context) -> usize
fn inline_size(_context: Context) -> usize
inline_align
.§fn encode_is_copy() -> bool
fn encode_is_copy() -> bool
Self::Owned
matches the FIDL wire
format and encoding requires no validation. When true, we can optimize
encoding arrays and vectors of Self::Owned
to a single memcpy. Read more§fn decode_is_copy() -> bool
fn decode_is_copy() -> bool
Self::Owned
matches the FIDL wire
format and decoding requires no validation. When true, we can optimize
decoding arrays and vectors of Self::Owned
to a single memcpy.Source§impl ValueTypeMarker for BufferCollectionConstraints
impl ValueTypeMarker for BufferCollectionConstraints
Source§type Borrowed<'a> = &'a BufferCollectionConstraints
type Borrowed<'a> = &'a BufferCollectionConstraints
Encode<Self>
type cheaply obtainable from &Self::Owned
. There are three cases: Read moreimpl Persistable for BufferCollectionConstraints
impl StructuralPartialEq for BufferCollectionConstraints
Auto Trait Implementations§
impl Freeze for BufferCollectionConstraints
impl RefUnwindSafe for BufferCollectionConstraints
impl Send for BufferCollectionConstraints
impl Sync for BufferCollectionConstraints
impl Unpin for BufferCollectionConstraints
impl UnwindSafe for BufferCollectionConstraints
Blanket Implementations§
§impl<T> Body for Twhere
T: Persistable,
impl<T> Body for Twhere
T: Persistable,
§type MarkerAtTopLevel = T
type MarkerAtTopLevel = T
§type MarkerInResultUnion = T
type MarkerInResultUnion = T
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§unsafe fn clone_to_uninit(&self, dst: *mut T)
unsafe fn clone_to_uninit(&self, dst: *mut T)
clone_to_uninit
)