Render Memory Chart from JSON description document

[dhingora-amd]

Motivation

The compute kernel-details Memory Chart was a static, hardcoded diagram that couldn't adapt to different GPU architectures or traces. This makes it data-driven: the memory hierarchy is described as JSON stored per-workload in the trace database, so the chart reflects each workload and can evolve without code changes.

Technical Details

• Relational layout model (rocprofvis_memory_chart_model.{h,cpp}): a set of blocks (nodes) and arrows (edges) parsed from JSON. Blocks nest via children (container boxes); metrics are referenced by their full dotted id category.table.entry; a semantic category drives accent colors. No coordinates in JSON — columns, block sizing, and arrow routing are computed at runtime.
• Layout from the database: new optional compute_workload.memory_chart_extdata column, detected via PRAGMA and plumbed model → controller C ABI (kRPVControllerWorkloadMemoryChartLayout) → data provider → view, with an embedded default (rocprofvis_memory_chart_default_layout.h) as fallback.
• Renderer (rocprofvis_compute_memory_chart.{cpp,h}): resolves the selected kernel's metric values and draws the chart. Skip-arrow routing packs "highway" lanes (horizontally disjoint arrows share a lane; shorter spans nest inside longer ones), spreads each block's bottom connectors symmetrically about its centre, and draws all lines before labels so no line is painted over a label.
• Docs updated (.agents/AGENTS.md)

[dhingora-amd]

memory_chart.schema.json
Above is the proposed schema.

[dhingora-amd]

memory_chart.schema.json
Updated Schema.

[drchen-amd]

Can you merge in latest main? Metrics for newer db versions are mapped incorrectly and there is a change that should address it.

A couple of issues from testing:

• Metric tooltips get cut off a few ticks above minimum font size.
• % metrics like hit rate and utilization now display without units where old version had them.

[drchen-amd]

This seems to lack a "render friendly" memory chart model, and as a result there is a fair amount of redundant processing to make it render friendly every frame. For example:

• ComputeMemoryChartView::MetricLabel - Returns a passed in overridden name if exists, otherwise metric name if metric exists.

• ComputeMemoryChartView::MetricValueText - Converts metric value to str, appends unit.

• Arrows and blocks searching for for which blocks they connect to.

There is a rocprofvis_memory_chart_model, but it is a collecting of helper functions and does not hold any data. This could be expanded to provide a "friendly" data representation. Rough idea being that it would store a bunch of these:

struct Metric
{
  int category, table, entry
  string name
  string value
}

struct Block
{
  int id,
  string name,
  vector<Metric> metrics
  Imvec2 x,ypos
  Imvec2 length,width
}

struct Arrow
{
  int id,
  int name,
  Metric metric
  Block* source
  Block* target
}

Then your ComputeMemoryChartView would update subsections of this only when needed:

• On workload change, your entire layout changes, so you would create fresh Blocks and Arrows.
• On kernel change, you go through your Arrows and Blocks, and update only the metric related data.

The sizing and positioning updates need to remain in render, but everything else would be ready as is for render to consume.

[tomk-amd]

Merging - but this should be addressed soon if real:

AI Review

The one real gap bug. Skip arrows (column distance greater than 1) mark every intervening gap as arrow-bearing, but they are not drawn through those corridors — they go under the blocks on the highway, or up the left margin. A skip from L2 to HBM would re-open the MALL/UMC gaps this change is trying to close. default.json already has a skip (13 → 1); those gaps stay wide today only because adjacent arrows also cross them.