Nick Smith

I think ideally we'd like to also support HWIO (i.e. `prepareWeightsChannelsLastForTTNN`), we might need to hand roll this ourselves because TTNN doesn't have a concept of host side ops.

This is manually done today, see `to_weight_tile_layout`, we need to add a similar routine (potentially tweak the existing routine) to prepare the weights from a HWIO source layout instead.

I think this issue was never fully completed. But at this point things are so entrenched, maybe it's not worth it to fix?

@pavlejosipovic Today the TTNN conv API is a bit inconsistent, typically there are 2 flavors of data layout: - [PyTorch style (Channels First)](https://docs.pytorch.org/docs/stable/generated/torch.nn.functional.conv2d.html) - Activations: `(N, inC, iH, iW)` -...

> Ok I see. Prepared weights are in this channel last fashion, but we would never be able to use existing data as is it would still have to go...

I see, so it's more involved than I thought.

This isn't super urgent, just filed the issue for tracking. Our main use case is to be used in tandem with https://github.com/tenstorrent/tt-metal/issues/10702, i.e. to make traces more portable. I think...

> Virtualizing traces/portability is a great feature. > > We can also consider using "virtual NOCs coord" (ie translated cords) , since we have HW support for these. Kernel wouldn't...

@pgkeller, are we going to use HW feature "NOC coordinate translation"?

Would love to get some input from torch-xla maintainers who'd have a much better feel for the scope of work here. Also, if it's already been thought about / considered.