Skip to content

LinxISA v0.4 Rendering PTO Contract

This document defines the live public contract for rendering-oriented PTO usage in canonical v0.4.

It freezes which block carriers are valid today, which TEPL selectors are already part of the canonical machine-readable catalog, and which rendering PTO names remain planning-only until a later catalog revision assigns them.

Scope

  • rendering-oriented use of PTO-style tile operations,
  • canonical mapping from rendering PTOs to current v0.4 block carriers,
  • rules for TEPL selector use,
  • explicit non-assignment of rendering PTO semantics to BSTART.FIXP in the current canonical profile.

This page is normative for rendering PTO naming and carrier selection in live v0.4 docs, examples, tests, and bring-up artifacts.

Carrier Rule

Canonical v0.4 rendering PTOs use these carriers:

  • BSTART.TEPL for header-driven template operations with assigned TileOpcode values,
  • BSTART.TMA aliases such as TLOAD, TSTORE, and TMOV for tile movement and tile-memory plumbing,
  • BSTART.CUBE aliases such as TMATMUL, TMATMUL.ACC, and ACCCVT for the current matrix/accumulator engine path,
  • BSTART.MPAR VEC kernels as the required functional fallback when no canonical TEPL or other hardened mapping exists.

BSTART.TEPL is the only canonical generic PTO carrier for rendering-oriented template ops in current v0.4.

BSTART.TEPL Rule

The authoritative selector catalog for canonical TEPL operations is:

  • isa/v0.4/state/engine_ops.json

The current canonical encoding rule is:

  • TileOpcode[9:6] MUST be zero,
  • TileOpcode[5] is TEPL Mode,
  • TileOpcode[4:0] is TEPL Function,
  • TileOpcode = (Mode << 5) | Function.

Rendering-facing docs, tests, and examples MUST use only TEPL selectors present in that catalog. Unassigned selector values remain reserved or illegal in canonical v0.4.

BSTART.FIXP Rule

BSTART.FIXP exists in the opcode catalog as a block-split form, but canonical v0.4 does not currently assign it a rendering PTO selector catalog, a machine-readable semantic profile, or a rendering-specific descriptor contract.

Therefore:

  • rendering PTOs MUST NOT be assigned to BSTART.FIXP in canonical v0.4 docs, AVS, examples, or normalized output,
  • new rendering operations MUST NOT be routed to BSTART.FIXP unless a later canonical revision adds:
  • machine-readable selector assignments,
  • manual semantics,
  • descriptor requirements,
  • and validation coverage.

In the current profile, BSTART.FIXP is not the canonical carrier for rendering PTO work.

Canonical Rendering-Relevant PTO Set Today

The following rendering-relevant PTO families already have canonical carriers in current v0.4.

Tile Utility And Data-Movement Primitives

These are canonical today through existing TMA, CUBE, or TEPL mappings:

  • TLOAD
  • TSTORE
  • TMOV
  • TCVT
  • TRESHAPE
  • TTRANSPOSE
  • TGATHER
  • TSCATTER
  • TCOLEXPAND
  • TROWEXPAND

Elementwise And Reduction Primitives

These are canonical today under assigned TEPL selectors and can be used as building blocks for rendering flows:

  • TADD, TSUB, TMUL, TDIV, TMAX, TMIN
  • TAND, TOR, TXOR, TSHL, TSHR
  • TRELU, TPRELU, TEXP, TLOG, TSQRT, TRSQRT, TRECIP
  • TROWMAX, TROWMIN, TROWSUM
  • TCOLMAX, TCOLMIN, TCOLSUM
  • scalar-RHS forms already assigned in TEPL mode 1: TADDS, TSUBS, TMULS, TDIVS, TMAXS, TMINS, TANDS, TORS, TXORS, TSHLS, TSHRS

These are the only rendering-friendly TEPL operations that are already frozen as canonical selectors today.

Rendering PTO Names That Are Not Yet Canonical Ops

The following draft rendering PTO names do not currently have canonical TEPL or FIXP assignments in v0.4:

  • TCLEAR
  • TPACK
  • TUNPACK
  • TSWZ
  • DEPTH_TEST
  • STENCIL_TEST_OP
  • BLEND
  • LOGIC_OP
  • INTERP_LINEAR
  • DERIV_QUAD
  • TEX2D_SAMPLE
  • TRI_SETUP
  • COVERAGE

In canonical v0.4, these names are planning-only. They MAY be discussed as future candidates, but they MUST NOT appear as if they were assigned TEPL or FIXP operations today.

Until a later revision assigns them explicitly, these functions must be realized by one of:

  • composition of existing canonical TMA, CUBE, and TEPL operations,
  • software or BCC-side scaffolding,
  • MPAR kernel implementations used as the architectural fallback path.

Descriptor And Memory Rules

Rendering PTOs carried under BSTART.TEPL remain subject to the existing header-driven tile-block rules:

  • they do not use B.TEXT,
  • tile and scalar bindings are expressed only through block descriptors,
  • descriptor requirements are op-profile-specific and come from the canonical TEPL op definition,
  • TEPL and TAU-facing rendering PTO execution remains tile-to-tile only,
  • any global-memory interaction must remain explicit through TMA, DMA, or VEC fallback paths.

This preserves alignment with the rendering profile and hardening policy.

Fallback Rule

Every rendering PTO path that uses a canonical TEPL building block MUST still have a correctness-preserving fallback path.

  • if the required TEPL selector does not exist, use composition or MPAR,
  • if a future hardened rendering op is introduced, keep MPAR as the required functional fallback until the new path is proven,
  • software-backed rendering baselines remain valid reference paths during bring-up.

Evolution Rule

Future rendering PTO growth must follow this order:

  1. define the operation contract,
  2. decide whether the carrier is TEPL, another existing typed block, or a new explicitly assigned family,
  3. add machine-readable selector state,
  4. add manual semantics and descriptor rules,
  5. add AVS and implementation validation.

Until those steps are complete, the operation is not part of canonical v0.4.