Placement guidance for external structured quaternion kernel benchmark

[RQM-Technologies-dev]

Hi Tenstorrent maintainers,

RQM Technologies has started an independent open-source project called tt-rqm-kernels.

The project defines CPU/PyTorch reference kernels and a benchmark suite called StructuredBench for structured tensor operators. The basic idea is simple: some things like rotation, phase, orientation, and other relationships are better represented with polar coordinates.

The first structure we are targeting is a quaternion-style four-lane value:

[N, 4] = [real, i, j, k]

In practical terms, this gives ordinary floating-point tensors a compact way to carry rotation, phase, orientation, and geometric state. That matters for workloads such as robotics pose updates, graphics rotation streams, wireless phase tracking, imaging pipelines, wave simulation, physical AI, scientific computing, and downstream defense applications.

The first proposed kernel is qmul, the Hamilton product for two [N, 4] inputs producing one [N, 4] output. The reason this is useful as a benchmark is that it is small enough to validate, but more structured than a generic elementwise operation: every output lane depends on every input lane through a fixed multiply/add/sign pattern.

Why this may be useful to Tenstorrent:

• It gives Tenstorrent a compact benchmark class between scalar elementwise ops and large matmul.
• It demonstrates structured numerical workloads beyond LLM inference and conventional neural-network layers.
• It is a good fit for a bottom-up custom-kernel path: CPU/PyTorch reference first, then a minimal TT-Metalium qmul example, then possible TT-NN wrapping later.
• It helps show how Tenstorrent hardware handles 4-lane structured values, fixed cross-lane dependencies, kernel fusion, data movement, and arithmetic intensity.
• It does not require a new datatype, new silicon feature, or native quaternion hardware. The representation stays inside ordinary floating-point tensors.

My question for you is:
Where should a minimal TT-Metalium qmul example for [N, 4] structured tensors live?

• If a TT-Metalium programming example is not the right starting point, is there a preferred TT-NN custom-op path?
• Would a TT-MLIR representation be useful later, after there is a concrete lower-stack qmul example?

StructuredBench currently reports throughput, latency, numerical error, estimated FLOPs/sec, effective GB/sec, arithmetic intensity, and scalar-reference spot-check error. The intent is to make future TT-Metalium or TT-NN results directly comparable against the CPU/PyTorch reference.

Repo:
RQM-Technologies-dev/tt-rqm-kernels

Relevant docs:

• docs/structuredbench-spec.md
• docs/operator-contracts.md
• docs/tenstorrent-rfc.md
• reports/tenstorrent_packet.md

Any guidance on preferred placement, benchmark format, or custom-op pathway would be appreciated.

[RQM-Technologies-dev]

Update: the kernel has now completed whole-output N300 validation, a three-session one-device stability qualification, and profiler diagnostics. Following the current contribution path, I opened a narrowly scoped feature issue for the remaining placement and layout decision: #49887

No implementation PR will be opened until maintainers indicate whether this belongs as a TT-Metalium programming example or an experimental TT-NN ProgramDescriptor operation.