feat(taxis): derive storage dtype from the element type [recovered; design proposal]

[forkwright]

Draft, and now a design proposal rather than a merge candidate. Read the last section before spending time here.

Correction to this PR's original description

It said this work "adds BytePod". That is wrong. BytePod is a pre-existing hipcore trait. What the commit adds is:

pub unsafe trait DTyped: BytePod { ... }
unsafe impl DTyped for f32 { ... }   // + f16, bf16, i32, i8, u8

DTyped binds a host element type to the runtime DType tag it represents, bounded on the existing BytePod. The branch name carries the same error and is not worth rewriting for.

Where it came from

Found uncommitted in the shared logismos clone on metis: five modified files, 141 insertions, no branch, no author, nothing but one machine's working tree keeping it alive. Committed at its true base (8b82822) rather than force-fitted onto a tree it was never written against.

What changed since: main got there first, twice

I attempted a rebase onto current main so CI could judge it. It conflicts, and the conflicts are the interesting part — main has independently solved both problems this work targets:

1. Zeroed device memory — same fix, already landed.

// main
let mut buffer = DeviceBuffer::<u8>::alloc(device, bytes)?;
// WARNING: `hipMalloc` does not zero device memory. ... closes forkwright/logismos#26.
buffer.zero_fill()?;

The branch makes the identical change with its own comment. Nothing left to take.

2. dtype/layout mismatch — same problem, different solution.

// main: validate the caller-supplied dtype
pub fn from_host<T: BytePod>(device: &Device, dtype: DType, data: &[T]) -> Result<Self> {
    Self::validate_dtype_matches::<T>(dtype)?;      // cites forkwright/logismos#40

// this branch: derive the dtype, so there is nothing to validate
pub fn from_host<T: DTyped>(device: &Device, data: &[T]) -> Result<Self>
// stored dtype comes from T::DTYPE

Main checks the mismatch. This branch makes it unrepresentable — no dtype parameter, so no way to pass one that disagrees with T's layout.

What is actually being asked

Not "merge this". The question is whether from_host should keep taking a dtype parameter and validate it, or derive it from T::DTYPE and drop the parameter.

That is a public API change with a real trade-off — the derived form removes a whole error class but constrains callers to types implementing DTyped, where the validated form accepts any BytePod and fails at runtime. It deserves a decision, not a conflict resolution.

I did not resolve the conflicts. Doing so would mean choosing that API change silently, inside merge markers, on code I did not write and have never compiled. The branch stays at its original base so the proposal is legible against the tree it was written against.

If the derived form is wanted

It needs reimplementing against current main rather than rebasing — main's validate_dtype_matches, its error variants, and its intra-doc #[expect(unused_imports)] blocks all postdate this work. The value here is the design and the DTyped impl list, not the diff.

If it is not

Close this and delete the branch. Nothing is lost that main does not already have, except the proposal above — and that is now written down here.