Struct Capabilities 

pub struct Capabilities {
    pub max_texture_size: u32,
    pub sample_counts: SampleCounts,
    pub dma_buf: DmaBufSupport,
    pub sync: SyncSupport,
    pub advanced_blend: bool,
    pub float_render_targets: bool,
    pub render_formats: Vec<FormatModifierSet>,
    pub device_name: String,
    pub driver_name: String,
    pub software: bool,
}

Everything the layers above the HAL are allowed to branch on.

Fields

max_texture_size: u32

Maximum width or height of a 2D texture.

sample_counts: SampleCounts

Supported MSAA sample counts for render targets.

dma_buf: DmaBufSupport

Cross-device image sharing.

sync: SyncSupport

Cross-component synchronization.

advanced_blend: bool

Whether the advanced blend modes are available.

Both kinds: the separable ones from Multiply through Exclusion and the four non-separable ones. What they share is the thing that matters here – BlendMode::factors has no pair to return for any of them – and what this does not gate is Porter-Duff, Plus or Modulate, which are factors and available everywhere.

They need a hardware extension and cannot be emulated with blend factors, so a device without it refuses BlendMode::is_advanced modes rather than substituting the nearest expressible one. Callers check this before using one; nothing branches on which backend is in play.

float_render_targets: bool

Whether a floating-point color attachment can be rendered into.

A color outside the sRGB primaries’ triangle has a component outside zero to one, and Rgba16Float is the only format here that can hold one. Whether a device will let it be a target is a separate question from whether it will sample one: half-float is filterable in core ES 3.0 and renderable only with an extension, and plenty of shipping drivers have the first and not the second. Vulkan answers per format from its format properties.

Distinct from Self::render_formats, which is the scanout list keyed by DRM fourcc and is empty on GLES. A format with no fourcc is deliberately absent from that list, so it cannot answer this.

render_formats: Vec<FormatModifierSet>

Formats and layouts this device can render into and export.

One half of format negotiation; the presentation target supplies the other.

device_name: String

Human-readable device and driver identification, for report fingerprints and bug reports.

driver_name: String

software: bool

Whether rendering happens on the CPU rather than on a GPU.

Not a performance hint. It marks the device properties that are consequences of having no graphics hardware rather than defects: a CPU rasterizer has no tiling to describe, so advertising only a linear layout is the correct answer for it and a sign of a missing modifier query on anything else. A test that cannot tell those apart has to choose between failing on software and not checking hardware, and both are worse than asking.

Vulkan takes this from the device type, which is authoritative. GLES has no equivalent query and it is recognized from the renderer string, which is not; a software implementation this does not know the name of reports false, so treat a true as reliable and a false as merely unremarkable.

Implementations

impl Capabilities

pub fn supports_scanout(&self) -> bool

Whether this device can drive a KMS plane directly, by either allocation strategy.

Note this says nothing about sync: a device can be scanout-capable and still lack fence export, in which case the path works with a CPU wait.

pub fn check_blend_modes(&self, batch: &Batch) -> Result<()>

Whether every blend mode a batch uses is available on this device.

Lives here rather than in each backend so the two refuse the same batch for the same reason: a Vulkan device without the advanced-blend extension and a GLES context without it are the same problem, and a check written twice is a check that eventually disagrees with itself. Refusing is deliberate — the alternative is substituting the nearest expressible mode, which produces a picture nobody can debug from.

pub fn check_texture(&self, desc: &TextureDescriptor) -> Result<()>

Whether this device can create the texture a descriptor asks for.

Here rather than in each backend for the reason Self::check_blend_modes is: two backends refusing the same thing for the same reason, in one place, rather than a check written twice that eventually disagrees with itself. Without it the failure arrives as a framebuffer-incomplete number on one backend and a driver error on the other, neither of which names what was missing.

pub fn can_allocate(&self, extent: Extent2D) -> bool

Whether an extent fits within the device’s texture limit.

Trait Implementations

impl Clone for Capabilities

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Capabilities

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Default for Capabilities

fn default() -> Self

Returns the “default value” for a type.