Struct DepthwiseTiling 

pub struct DepthwiseTiling {
    pub rows: usize,
    pub cols: usize,
    pub chans: usize,
    pub lines: usize,
}

How one cube’s share of the output is shaped, and how the cube’s threads divide it.

The three numbers are three different jobs, which is why they are not one “tile size”:

• rows is the plane count. One plane per output row, so it is what fills the cube.
• cols is the accumulator block one lane keeps in registers. Every column of it re-reads the same filter and overlapping input, so it is what amortises both.
• chans is how many channel lines one lane owns. Lanes are dealt lines interleaved, so whatever this is, consecutive lanes still read consecutive channels and the read coalesces.
• lines is how many channels one of those lines covers — the width every operand is served in. It is the one knob that trades the two things a depthwise pass is limited by against each other, which is why it is stated and not derived: a wider line is fewer instructions per channel, and also more registers per lane and a wider channel tile, so fewer lanes with anything to do when the block is narrow. It is a ceiling, not a demand — the launch drops to what the buffers can actually be served in.

The cube’s channel tile is plane_size · lines · chans.

Fields

rows: usize

cols: usize

chans: usize

lines: usize

Implementations

impl DepthwiseTiling

pub fn for_problem(channels: usize, taps: usize, lanes: usize) -> Self

The tiling to run a problem of this shape under.

Only lines is decided here, and it is close to a single question: is this convolution short of instructions or short of bandwidth? A wide line is four times fewer instructions per channel, and also four times the registers per lane and a four-times wider channel tile. A deep window over a wide block is instruction-bound and takes the trade; everything else is already reading memory as fast as the device will read it, and pays the registers for nothing.

Both thresholds are where that turnover was observed rather than where a model of the hardware puts it, so this is a derivation a device is allowed to disagree with. The depthwise benchmark catalogue is the instrument that settles it: running its Fixed entries against Routine is what says whether this rule still picks the right line.

Trait Implementations

impl Clone for DepthwiseTiling

fn clone(&self) -> Self

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Copy for DepthwiseTiling

impl Debug for DepthwiseTiling

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

Formats the value using the given formatter.

impl Default for DepthwiseTiling

fn default() -> Self

Four planes of one row each, four output columns per lane, scalar channels.

Small on both spatial axes on purpose: the window overlaps, so a cube’s halo is what it re-reads, but a wide tile is also what pushes its far corner past the padded border and costs every instance in it the guarded walk. Four each is where those two meet on the shapes an encoder actually runs. The line width is the knob worth deciding per problem, which for_problem is.

impl Eq for DepthwiseTiling

impl Hash for DepthwiseTiling

fn hash<__H: Hasher>(&self, state: &mut __H)

Feeds this value into the given Hasher.

fn hash_slice<H>(data: &[Self], state: &mut H)

where H: Hasher, Self: Sized,

Feeds a slice of this type into the given Hasher.

impl PartialEq for DepthwiseTiling

fn eq(&self, other: &Self) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for DepthwiseTiling