Linking reports

TT-NN Visualizer can attempt to link the current active memory and performance reports to provide additional data insights. This is only possible when the two reports are from the same run.

The current link status is indicated in the UI when both a memory and performance report are loaded. If reports fail to link it is likely they are not from the same run.

Successful link Reports are linked

Failed link Reports cannot be linked

Finding linked reports in the report pickers

The report pickers list reports newest first, and nothing in the pickers reorders them:

  • Local reports are ordered by when their folder was last modified. Uploading a report counts as a modification.

  • Remote reports are ordered by when they were last modified on the remote machine.

  • When only the locally synced copies of remote reports can be listed, they are ordered by when they were synced. A copy with no record of its sync is ordered by when its folder was last modified.

Some cases do not follow this order yet (#2209):

  • Reports with the same time can appear in any order. On the hosted app that order can change when the app restarts. Remote times are recorded to the second, so the ranks of one multi-host run often share one.

  • After you sync a single remote report, it keeps its place in the list until the list is fetched again.

  • On remote machines whose stat command is not the GNU version, such as macOS, every remote report gets the same time, so the list is not in date order.

Once the active report of the other kind has been linked, or has failed to link, with at least one report, each row carries a link badge: linked, failed to link, or not yet known. A memory report picker shows its badges against the active performance report, and a performance report picker shows them against the active memory report. An active report that has never been paired shows no badges.

To list only the reports linked to the active one, press the link button in the picker’s filter box. It works together with the text filter, and it appears only while the picker is showing badges. If the badges go away, the button turns off.

Allocation failures in the performance view

When the linked memory report records allocation failures, the performance table lists them in a callout above it. See Allocation failures, under “In the performance view”.

Likely DRAM fallbacks

tt-metal records nothing when a tensor that would normally live in L1 ends up in DRAM, so the performance view infers it from the linked memory report. Rows of an operation that probably fell back carry a DRAM fallback? flag in the Flags column. The question mark is deliberate: treat the flag as a lead to check, not a fact. Its tooltip says which of these signals raised it:

  • Requested L1, got DRAM. Every memory config the operation was given asks for L1, yet an output it allocated is in DRAM. Only values printed as MemoryConfig(...) or tt::tt_metal::MemoryConfig(...) count. Intermediate memory configs are ignored, because they say nothing about where the output should go. A memory config whose buffer type can’t be read counts as not asking for L1.

  • Retry after an L1 failure. An operation failed to allocate L1, and the first same-named operation within the next three is in DRAM. This is the “try L1, fall back to DRAM” pattern in a script. If that operation stayed in L1, the retry worked and nothing is flagged. An L1 bank failure counts unless the failed operation asked for DRAM. A circular-buffer failure concerns the program’s buffers rather than the output, so it counts only when the failed operation asked for L1.

An operation with any output in L1 is never flagged. Conv operations also return their prepared weights and bias, which are always new DRAM buffers, so an L1 output means the output that was asked for stayed in L1.

An output with the same element count, at the same DRAM address as one of the operation’s DRAM inputs on every device both are on, is a view of that input, not a fallback; ttnn.reshape returns one and ignores its memory config. Those outputs are never flagged, and neither is a DRAM output with the same element count as a DRAM input, or with a shape that can’t be read, when either one’s address is unknown, since it may be a view. L1 and each device’s DRAM are separate address spaces, so a matching number there does not count.

The flag appears only when the two reports are linked. It does not catch a fallback when L1 was only implied. For example, ttnn.split given no memory config puts its output where its input is, and moves that output to DRAM when an L1 input’s chunks won’t fit. No argument records that L1 was expected, so nothing in the report shows the request it overrode. A general version of that check would mostly flag ops whose default output is simply DRAM (#2096).