Support ComputeConfig::unpack_to_dest_mode

[nsmithtt]

Metal replaced computeConfig.preserve_fp32_precision with unpack_to_dest_mode:

enum class UnpackToDestMode : uint8_t    
{    
    UnpackToDestFp32,    
    Default    
}; 

struct ComputeConfig {
    ...
    std::vector<UnpackToDestMode> unpack_to_dest_mode;
};

We need to update:

• TTKernelOpsEnums.td: Add UnpackToDestMode enum
• TTKernelOpsTypes.td: Update TensixConfigAttr w/ new ArrayAttr field unpack_to_dest_mode (one per CB)
• TTMetal/program.fbs: Update table TensixConfig
• ttmetal/command_queue.cpp: Plumb through to metal api

[nsmithtt]

preserve_fp32_precision was removed as part of:

• Uplift third_party/tt-metal to origin/main 2024-10-24 #870

[kmabeeTT]

Going to look at this now

[kmabeeTT]

Hey @nsmithtt - tt-metal requires the new enum to be set for either none, or all 32 CBs with this assert they have:

    if (!unpack_to_dest_mode.empty()) {
        TT_FATAL(unpack_to_dest_mode.size() == NUM_CIRCULAR_BUFFERS, "unpack_to_dest_mode vector must have 32 elements");
    }

I don't see we have this type of variable NUM_CIRCULAR_BUFFERS=32 replicated on our side anywhere. On their side it comes from here:

tt_metal/hostdevcommon/common_runtime_address_map.h:constexpr static std::uint32_t NUM_CIRCULAR_BUFFERS = 32;

2 questions:

1. Rather than reach into metal runtime and use this variable on our side (bad idea right?) I think we want to get this officially from tt-metal (into our system-desc) using the same (not yet ready) API that some of our other tt-mlir runtime tickets (like [SystemDesc] List supported tile sizes and data formats #433, Get memory alignment from device #300) are pending on, what do you think?

2. Since that is pending for a couple months already, I propose to replicate/hardcode value 32 in TTIRToTTMetal.cpp creation of TensixConfigAttr so it can populate all 32 values with UnpackToDescMode::Default to preserve existing behavior today and open ticket to remove workaround once metal provides it via API. Any concerns?

[nsmithtt]

Completely agree with both points:

1. Let's get it properly made to be metal API and plumb it through system desc.
2. Hard coding for now makes sense.

Seems weird that it must be specified for all circular buffers TBH, could make sense for metal to make this a std::array if it's expected to be a hard coded size.

[kmabeeTT]

Opened a metal ticket tenstorrent/tt-metal#14066 after offline discussion to request that requirement be removed, then don't need to export up via systemdesc (unless you think we want it anyways, for other purposes).

[nsmithtt]

Opened a metal ticket tenstorrent/tt-metal#14066 after offline discussion to request that requirement be removed, then don't need to export up via systemdesc (unless you think we want it anyways, for other purposes).

Sounds good. We might need it anyway to know what the max number of CBs is. What we probably want actually is a breakdown:

• 8 input
• 8 dataflow
• 8 outputs
• 8 intermediates

This is almost inferable from tt-metal's enum CB.

If the above metal ticket gets fixed, then this issue a much lower priority. We already have to model these CB's in TTKernel dialect which I think would make it impossible to emit more of each type already.