Trait Microkernel 

pub trait Microkernel:
    Debug
    + Clone
    + PartialEq
    + Sized {
    type WorkItem: Debug + Clone;
    type Settings: Debug + Clone + Display;
    type Operand: Debug + Copy + Eq;
    type CubeSpace: Debug + Clone;

    const DECLINE: &'static str;

    // Required methods
    fn settings(hw: &Hardware) -> Vec<Self::Settings>;
    fn candidates(
        hw: &Hardware,
        item: &Self::WorkItem,
        settings: &Self::Settings,
    ) -> impl Iterator<Item = Self>;
    fn vectorize(
        &self,
        cube_space: &Self::CubeSpace,
        vectorization: &mut Vectorization<Self::Operand>,
    );
    fn estimate(
        &self,
        item: &Self::WorkItem,
        cube_space: &Self::CubeSpace,
        planes: CubePlanes,
        estimate: &mut KernelEstimate,
    );

    // Provided methods
    fn admits(_item: &Self::WorkItem) -> Result<(), Refusal> { ... }
    fn decline(_settings: &Self::Settings) -> &'static str { ... }
    fn best(
        hw: &Hardware,
        item: &Self::WorkItem,
        settings: &Self::Settings,
    ) -> Result<Self, Refusal> { ... }
}

What one owner of a work item runs.

A value: the choice the hardware settled, sized by its settings, holding the microkernel it is built from where it is built from one. Its scope is in its name.

Required Associated Constants

const DECLINE: &'static str

Why candidates comes back empty on a device, when it does.

Required Associated Types

type WorkItem: Debug + Clone

What one owner is handed, as far as the choice of microkernel depends on it.

type Settings: Debug + Clone + Display

The knobs a measurement settles.

type Operand: Debug + Copy + Eq

How the family names its operands, for Vectorization.

type CubeSpace: Debug + Clone

The part of the problem one cube covers, as much of it as this microkernel reads: () for one that reads only its own tiling. Where the cubes lie is its routine’s placement.

Required Methods

fn settings(hw: &Hardware) -> Vec<Self::Settings>

The settings worth trying on this device, its default first: its own knobs, each setting holding the one option it picked of the microkernel it is built from. A routine built on it lists these, each at its own default, before it varies its own knobs; a microkernel built on it picks from them by name.

fn candidates( hw: &Hardware, item: &Self::WorkItem, settings: &Self::Settings, ) -> impl Iterator<Item = Self>

Every microkernel this device can run item as, best first; empty where it can run none.

An iterator, and one that allocates nothing: best takes its first item on every prepare, so a list built to be read once would be built on every launch.

fn vectorize( &self, cube_space: &Self::CubeSpace, vectorization: &mut Vectorization<Self::Operand>, )

Enqueue what the accesses this microkernel’s own code makes to the tiles it is handed require of their widths, its cube covering cube_space, then hand vectorization to the microkernels it is built from. Where those tiles live is its walker’s to know, not its own.

fn estimate( &self, item: &Self::WorkItem, cube_space: &Self::CubeSpace, planes: CubePlanes, estimate: &mut KernelEstimate, )

Set in estimate the parts this microkernel owns of a kernel running item, each of its cubes of planes covering cube_space, then hand estimate to the microkernel it is built from: the staging where it places the stage’s reads, the work where its units hold it.

Provided Methods

fn admits(_item: &Self::WorkItem) -> Result<(), Refusal>

Whether this microkernel serves item on any device, and why not where it does not: what best reports before DECLINE, which then names what a device lacks. Every item, where it can say nothing finer.

Errors

The reason this microkernel serves no such item.

fn decline(_settings: &Self::Settings) -> &'static str

Why candidates comes back empty at settings: DECLINE, where no setting asks the device for something finer.

fn best( hw: &Hardware, item: &Self::WorkItem, settings: &Self::Settings, ) -> Result<Self, Refusal>

The best candidate.

Errors

admits’s reason, then decline’s where this device runs none.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors