Skip to content

feat(rocprofiler-compute): memory chart using json layouts - #12548

Merged
xuchen-amd merged 23 commits into
rocprofiler-compute-developfrom
users/xuchen-amd/memory_chart_json_layouts
Oct 17, 2026
Merged

xuchen-amd merged 23 commits into
rocprofiler-compute-developfrom
users/xuchen-amd/memory_chart_json_layouts

Conversation

@xuchen-amd

@xuchen-amd xuchen-amd commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Motivation

The memory chart for every architecture is now drawn by one renderer from a JSON layout file, one per architecture family. Adding an architecture means adding a layout file; no Python changes.

The layout file is also the memory chart contract with ROCm Optiq. It states everything needed to draw the chart, so Optiq reads it directly. #12582 stores it in the analysis database.

Bugfix: the Memory Chart tables keep their titles when the chart is not drawn (baseline comparison with several workloads).

Technical Details

  • Layouts (src/memory_chart/layouts/*.json): every block states where it goes (column, order, position, parent or host), every arrow states its direction, and each part states how it is drawn (block style, metric bar, arrow style).
  • Loader (loader.py) checks a layout against the format rules. A broken file is skipped with a warning, so only its architectures lose the chart.
  • Renderer (render.py) replaces the per-architecture mem_chart_*.py files and reads the layout fields instead of deriving them.
  • README (src/memory_chart/README.md) is the contract: every field, how to draw a layout, the rules a reader can rely on, and where to find each metric's value in the analysis database.
  • Tools: tools/memory_chart_layout_format.py (pre-commit formatter) and tools/memory_chart_preview.py <arch> (draws a layout without a GPU).

Chart changes users will see:

  • The boxes in the columns share one width, sized to the widest box; arrows are sized to fit their labels and values.
  • gfx1250 adds instruction cache, scalar data cache, and GL1 latency metrics; gfx115x shows instruction and data cache bandwidth separately.
  • Percent values get a progress bar on every architecture.
  • Labels such as the memory type are part of the block title, for example DRAM (DDR5/LPDDR5).

Issue Tracking

JIRA ID: AIPROFCOMP-683

Test Plan

  • python -m pytest tests/unit tools/test_memory_chart_*.py and project pre-commit.
  • tools/memory_chart_preview.py <arch> for every architecture, with full values, no values, and memory bandwidth stalls.
  • rocprof-compute analyze -p <gfx950 workload> -b 3, with one workload and with two.

Test Result

  • 1604 tests pass at the tip; pre-commit passes.
  • The chart draws for every architecture, and each layout shows every metric of its memory chart panel and no other.
  • With two workloads, the Memory Chart tables keep their titles.

Submission Checklist

@github-actions github-actions Bot added documentation Improvements or additions to documentation project: rocprofiler-compute labels Sep 30, 2026
@xuchen-amd
xuchen-amd force-pushed the users/xuchen-amd/memory_chart_json_layouts branch 2 times, most recently from 8be6a39 to 4d77f6e Compare September 30, 2026 15:53
@xuchen-amd
xuchen-amd changed the base branch from rocprofiler-compute-develop to users/xuchen-amd/memory_chart_improvements September 30, 2026 15:53
@xuchen-amd
xuchen-amd added this pull request to stack #12559 September 30, 2026 17:15
@xuchen-amd
xuchen-amd removed this pull request from stack #12559 September 30, 2026 17:28
@xuchen-amd
xuchen-amd added this pull request to stack #12562 September 30, 2026 17:29
@xuchen-amd
xuchen-amd force-pushed the users/xuchen-amd/memory_chart_json_layouts branch from 4d77f6e to 482a614 Compare September 30, 2026 18:05
@xuchen-amd
xuchen-amd removed this pull request from stack #12562 October 2, 2026 15:03
Base automatically changed from users/xuchen-amd/memory_chart_improvements to rocprofiler-compute-develop October 7, 2026 15:50
@xuchen-amd
xuchen-amd force-pushed the users/xuchen-amd/memory_chart_json_layouts branch from 482a614 to 34ad199 Compare October 7, 2026 21:45
@xuchen-amd xuchen-amd changed the title feat(rocprofiler-compute-develop): memory chart using json layouts feat(rocprofiler-compute): draw memory charts from JSON layouts Oct 7, 2026
@xuchen-amd
xuchen-amd requested a lite review from Copilot October 7, 2026 21:55
@xuchen-amd xuchen-amd changed the title feat(rocprofiler-compute): draw memory charts from JSON layouts feat(rocprofiler-compute): memory chart using json layouts Oct 7, 2026
@xuchen-amd
xuchen-amd force-pushed the users/xuchen-amd/memory_chart_json_layouts branch from 34ad199 to 289b37f Compare October 7, 2026 21:59

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

The changes require final human review because they are too complex or risky for automated approval.

0 open findings

What changed in this PR

Introduces a layout-driven memory chart renderer supporting multiple GPU architecture families without architecture-specific Python code.

Changes:

  • Adds JSON layouts, validation, unit formatting, rendering, preview, and canonical formatting tools.
  • Integrates the renderer into TTY output and preserves table headings when charts are unavailable.
  • Replaces architecture-specific renderers and updates tests, documentation, installation, and changelog.
File Description
projects/​rocprofiler-compute/​tools/​test_memory_chart_preview.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tools/​test_memory_chart_layout_format.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tools/​memory_chart_preview.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tools/​memory_chart_layout_format.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​utils/​test_tty.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​utils/​test_mem_chart_gfx9.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​utils/​test_mem_chart_gfx1250.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​utils/​test_mem_chart_gfx11.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​utils/​test_mem_chart_common.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​memory_chart/​test_units.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​memory_chart/​test_mem_chart.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​memory_chart/​test_loader.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​memory_chart/​layout_cases.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​unit/​memory_chart/​__init__.py Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​test_categories.yaml Updated as part of this pull request.
projects/​rocprofiler-compute/​tests/​integration/​test_num_xcds.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​utils/​tty.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​utils/​mem_chart_gfx9.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​utils/​mem_chart_gfx1250.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​utils/​mem_chart_gfx11.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​utils/​mem_chart_common.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​units.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​mem_chart.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​loader.py Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​layouts/​gfx950.json Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​layouts/​gfx94x.json Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​layouts/​gfx90x.json Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​layouts/​gfx1250.json Updated as part of this pull request.
projects/​rocprofiler-compute/​src/​memory_chart/​layouts/​gfx115x.json Updated as part of this pull request.
projects/​rocprofiler-compute/​docs/​how-to/​analyze/​cli.rst Updated as part of this pull request.
projects/​rocprofiler-compute/​docs/​design/​lld-membw-guided-analysis-in-memchart.md Updated as part of this pull request.
projects/​rocprofiler-compute/​docs/​design/​hld-membw-guided-analysis-in-memchart.md Updated as part of this pull request.
projects/​rocprofiler-compute/​CONTRIBUTING.md Updated as part of this pull request.
projects/​rocprofiler-compute/​CMakeLists.txt Updated as part of this pull request.
projects/​rocprofiler-compute/​CHANGELOG.md Updated as part of this pull request.
projects/​rocprofiler-compute/​.pre-commit-config.yaml Updated as part of this pull request.

🧠 Review effort: Lite


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@xuchen-amd
xuchen-amd marked this pull request as ready for review October 7, 2026 22:02
@xuchen-amd
xuchen-amd requested review from a team and prbasyal-amd as code owners October 7, 2026 22:02
@xuchen-amd
xuchen-amd added this pull request to stack #13066 October 7, 2026 23:04

@abchoudh-amd abchoudh-amd left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some minor comments. Overall looks good.

@vedithal-amd vedithal-amd left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will review

xuchen-amd added a commit that referenced this pull request Oct 8, 2026
…xuchen-amd/memory_chart_db_structure

Picks up the rocprofiler-compute-develop merge on #12548.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
xuchen-amd and others added 14 commits October 13, 2026 17:40
CONTRIBUTING.md gives the steps for adding an architecture and documents the
layout fields and categories.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… pytest path

Scripts in tools/ add src/ to sys.path before importing from it, so ruff now
ignores E402 for tools/ in pyproject.toml instead of each import carrying an
inline noqa. Adding tools/ to the pytest pythonpath lets the memory chart tool
tests import the scripts without editing sys.path.

This drops the inline noqa and sys.path edits from the memory chart tools added
in this PR. The older tools/ scripts are left for a follow-up.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ADME

The layout reference was too long for CONTRIBUTING.md. It now lives in
src/memory_chart/README.md, next to the layouts, with an annotated example and
short definitions of each field. CONTRIBUTING.md keeps a pointer, as it does for
metric management and vendoring.

The guide now says "memory chart panel" instead of "panel 300".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… membw LLD

The Renderer Changes section described the builders of the old gfx9 renderer
(build_cache_panel, bw_color, PeakBandwidths, build_legend) and the old
plot_mem_chart signature. It now describes the current code: stall rows go in
blocks with a stall_level in the JSON layout, the legend's stall entry, the
current plot_mem_chart and guidance renderer signatures, and the renderer in
the references.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…rt CLI docs

The paragraph said twice that the chart width does not follow the terminal.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- List the metrics the gfx1250 Memory Chart gained as sub-bullets.
- Name baseline comparison as the case where the Memory Chart tables lost
  their titles; it is the only case where the chart is not drawn.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- It is a general text helper used by tty, tests, and tools, not by the chart.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- plot_mem_chart and the stall helpers take MemBwAnalysisResult and
  BottleneckNode instead of Any.
- The membw tree spec and the layout loader share BOTTLENECK_LEVELS.
- Stall rows use the new PERCENT display unit.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- The row-height rules move to _heights; the module docstring points to the
  README.
- Rename _x to _column_left_edge, and import plot_mem_chart without an alias.
- Say "memory chart panel" instead of "panel 300".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Bugfix: a missing file, invalid JSON, or a non-object layout now goes
  through console_error like other layout errors, instead of a traceback.
- Loader tests check errors with common.patch_console.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- One constant for the analysis-config directory, used by utils_common,
  soc_base, and code_object_analysis.
- argparser still builds --config-dir from the home it is passed.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- PanelConfigs.for_arch reads an arch's memory chart panel once; the tests and
  the preview tool use it.
- The panel is found by its mem_chart cli_style (is_memory_chart_panel, moved
  from tty), not by panel id.
- The preview tool takes only an arch or a layout file.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- memory_chart/render.py, test_render.py, and the CTest test_memory_chart_render
  keep the test name matching its source module without repeating the package.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… exiting

A layout file that fails to load is skipped with a warning, so only its
architectures lose the chart. The formatter still fails on it. The preview
tool takes only an architecture, and the README describes count arrows
without the normalization placeholder.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@vedithal-amd
vedithal-amd force-pushed the users/xuchen-amd/memory_chart_json_layouts branch from 2dbcf48 to c27e27b Compare October 13, 2026 17:55
@xuchen-amd
xuchen-amd marked this pull request as draft October 14, 2026 21:23
xuchen-amd and others added 4 commits October 15, 2026 14:55
…awing hints

- Layouts list every block in one flat list with its column, order,
  position, and parent or host, so a reader draws the chart without
  working anything out from where an entry sits in the file.
- Arrows state their direction, and blocks, metrics, and arrows state how
  they are drawn (block style, metric bar, arrow style). The terminal
  renderer reads these instead of deriving them from the column, unit,
  and category.
- Block notes are part of the block title, for example "DRAM (DDR5/LPDDR5)".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ntract

- Describe every layout field, how to draw a layout step by step, the rules a
  reader can rely on, and how to find each metric's value and unit in the
  analysis database, so tools such as ROCm Optiq need only this page.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- The loader groups blocks into stacks under one key, the owner block (or
  none for a column), position, and column, and builds every stack the same
  way.
- Layout.top_level_blocks() replaces the column-flattening loops.
- The layout formatter starts each column after the first with a blank line
  by looking up its first block.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- The bordered boxes in the columns share the width of the widest one, so
  the grid is even again, as before the layout-driven renderer. The compact
  compute list keeps its own width.
- A scope label that needs more room widens every box, so they stay one
  width.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@xuchen-amd
xuchen-amd marked this pull request as ready for review October 15, 2026 21:06
@xuchen-amd
xuchen-amd merged commit 0206378 into rocprofiler-compute-develop Oct 17, 2026
75 checks passed
@xuchen-amd
xuchen-amd deleted the users/xuchen-amd/memory_chart_json_layouts branch October 17, 2026 02:24
xuchen-amd added a commit that referenced this pull request Oct 17, 2026
…analysis db (#12582)

## Motivation

ROCm Optiq can draw the memory chart from the analysis database alone.
Each workload stores its memory chart layout file unchanged, so the
layout file (#12548) is the only memory chart format.

Bugfix: a GPU whose layout file was skipped as broken no longer stops
the database output.

## Technical Details

- New JSON column `compute_workload.memory_chart_layout_extdata`: the
workload's layout file, or null when its GPU has no layout. Schema
version 2.4.0.
- Layout metrics are panel 3 metric names, unique within panel 3.
Readers find each value and unit in the existing metric tables;
`src/memory_chart/README.md` says how.
- No conversion, metric ids, or format version are stored.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- On real gfx950 workloads (one and two in a database, and with `-b 2`):
`analyze --output-format db`, then draw the chart from the database with
a reader written only from the README.

## Test Result

- 1606 tests pass at the tip; pre-commit passes.
- The stored column equals the layout file, and every layout metric
finds its value.
- The chart drawn from the database matches the terminal `analyze -b 3`
chart byte for byte.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
vedithal-amd added a commit that referenced this pull request Oct 25, 2026
## Motivation

The memory chart for every architecture is now drawn by one renderer
from a JSON layout file, one per architecture family. Adding an
architecture means adding a layout file; no Python changes.

The layout file is also the memory chart contract with ROCm Optiq. It
states everything needed to draw the chart, so Optiq reads it directly.
#12582 stores it in the analysis database.

Bugfix: the Memory Chart tables keep their titles when the chart is not
drawn (baseline comparison with several workloads).

## Technical Details

- **Layouts** (`src/memory_chart/layouts/*.json`): every block states
where it goes (`column`, `order`, `position`, `parent` or `host`), every
arrow states its `direction`, and each part states how it is drawn
(block `style`, metric `bar`, arrow `style`).
- **Loader** (`loader.py`) checks a layout against the format rules. A
broken file is skipped with a warning, so only its architectures lose
the chart.
- **Renderer** (`render.py`) replaces the per-architecture
`mem_chart_*.py` files and reads the layout fields instead of deriving
them.
- **README** (`src/memory_chart/README.md`) is the contract: every
field, how to draw a layout, the rules a reader can rely on, and where
to find each metric's value in the analysis database.
- **Tools:** `tools/memory_chart_layout_format.py` (pre-commit
formatter) and `tools/memory_chart_preview.py <arch>` (draws a layout
without a GPU).

Chart changes users will see:
- The boxes in the columns share one width, sized to the widest box;
arrows are sized to fit their labels and values.
- gfx1250 adds instruction cache, scalar data cache, and GL1 latency
metrics; gfx115x shows instruction and data cache bandwidth separately.
- Percent values get a progress bar on every architecture.
- Labels such as the memory type are part of the block title, for
example `DRAM (DDR5/LPDDR5)`.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- `tools/memory_chart_preview.py <arch>` for every architecture, with
full values, no values, and memory bandwidth stalls.
- `rocprof-compute analyze -p <gfx950 workload> -b 3`, with one workload
and with two.

## Test Result

- 1604 tests pass at the tip; pre-commit passes.
- The chart draws for every architecture, and each layout shows every
metric of its memory chart panel and no other.
- With two workloads, the Memory Chart tables keep their titles.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
vedithal-amd added a commit that referenced this pull request Oct 25, 2026
…analysis db (#12582)

## Motivation

ROCm Optiq can draw the memory chart from the analysis database alone.
Each workload stores its memory chart layout file unchanged, so the
layout file (#12548) is the only memory chart format.

Bugfix: a GPU whose layout file was skipped as broken no longer stops
the database output.

## Technical Details

- New JSON column `compute_workload.memory_chart_layout_extdata`: the
workload's layout file, or null when its GPU has no layout. Schema
version 2.4.0.
- Layout metrics are panel 3 metric names, unique within panel 3.
Readers find each value and unit in the existing metric tables;
`src/memory_chart/README.md` says how.
- No conversion, metric ids, or format version are stored.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- On real gfx950 workloads (one and two in a database, and with `-b 2`):
`analyze --output-format db`, then draw the chart from the database with
a reader written only from the README.

## Test Result

- 1606 tests pass at the tip; pre-commit passes.
- The stored column equals the layout file, and every layout metric
finds its value.
- The chart drawn from the database matches the terminal `analyze -b 3`
chart byte for byte.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
vedithal-amd added a commit that referenced this pull request Oct 26, 2026
## Motivation

The memory chart for every architecture is now drawn by one renderer
from a JSON layout file, one per architecture family. Adding an
architecture means adding a layout file; no Python changes.

The layout file is also the memory chart contract with ROCm Optiq. It
states everything needed to draw the chart, so Optiq reads it directly.
#12582 stores it in the analysis database.

Bugfix: the Memory Chart tables keep their titles when the chart is not
drawn (baseline comparison with several workloads).

## Technical Details

- **Layouts** (`src/memory_chart/layouts/*.json`): every block states
where it goes (`column`, `order`, `position`, `parent` or `host`), every
arrow states its `direction`, and each part states how it is drawn
(block `style`, metric `bar`, arrow `style`).
- **Loader** (`loader.py`) checks a layout against the format rules. A
broken file is skipped with a warning, so only its architectures lose
the chart.
- **Renderer** (`render.py`) replaces the per-architecture
`mem_chart_*.py` files and reads the layout fields instead of deriving
them.
- **README** (`src/memory_chart/README.md`) is the contract: every
field, how to draw a layout, the rules a reader can rely on, and where
to find each metric's value in the analysis database.
- **Tools:** `tools/memory_chart_layout_format.py` (pre-commit
formatter) and `tools/memory_chart_preview.py <arch>` (draws a layout
without a GPU).

Chart changes users will see:
- The boxes in the columns share one width, sized to the widest box;
arrows are sized to fit their labels and values.
- gfx1250 adds instruction cache, scalar data cache, and GL1 latency
metrics; gfx115x shows instruction and data cache bandwidth separately.
- Percent values get a progress bar on every architecture.
- Labels such as the memory type are part of the block title, for
example `DRAM (DDR5/LPDDR5)`.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- `tools/memory_chart_preview.py <arch>` for every architecture, with
full values, no values, and memory bandwidth stalls.
- `rocprof-compute analyze -p <gfx950 workload> -b 3`, with one workload
and with two.

## Test Result

- 1604 tests pass at the tip; pre-commit passes.
- The chart draws for every architecture, and each layout shows every
metric of its memory chart panel and no other.
- With two workloads, the Memory Chart tables keep their titles.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
vedithal-amd added a commit that referenced this pull request Oct 26, 2026
…analysis db (#12582)

## Motivation

ROCm Optiq can draw the memory chart from the analysis database alone.
Each workload stores its memory chart layout file unchanged, so the
layout file (#12548) is the only memory chart format.

Bugfix: a GPU whose layout file was skipped as broken no longer stops
the database output.

## Technical Details

- New JSON column `compute_workload.memory_chart_layout_extdata`: the
workload's layout file, or null when its GPU has no layout. Schema
version 2.4.0.
- Layout metrics are panel 3 metric names, unique within panel 3.
Readers find each value and unit in the existing metric tables;
`src/memory_chart/README.md` says how.
- No conversion, metric ids, or format version are stored.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- On real gfx950 workloads (one and two in a database, and with `-b 2`):
`analyze --output-format db`, then draw the chart from the database with
a reader written only from the README.

## Test Result

- 1606 tests pass at the tip; pre-commit passes.
- The stored column equals the layout file, and every layout metric
finds its value.
- The chart drawn from the database matches the terminal `analyze -b 3`
chart byte for byte.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
lamikr pushed a commit that referenced this pull request Oct 27, 2026
## Motivation

The memory chart for every architecture is now drawn by one renderer
from a JSON layout file, one per architecture family. Adding an
architecture means adding a layout file; no Python changes.

The layout file is also the memory chart contract with ROCm Optiq. It
states everything needed to draw the chart, so Optiq reads it directly.
#12582 stores it in the analysis database.

Bugfix: the Memory Chart tables keep their titles when the chart is not
drawn (baseline comparison with several workloads).

## Technical Details

- **Layouts** (`src/memory_chart/layouts/*.json`): every block states
where it goes (`column`, `order`, `position`, `parent` or `host`), every
arrow states its `direction`, and each part states how it is drawn
(block `style`, metric `bar`, arrow `style`).
- **Loader** (`loader.py`) checks a layout against the format rules. A
broken file is skipped with a warning, so only its architectures lose
the chart.
- **Renderer** (`render.py`) replaces the per-architecture
`mem_chart_*.py` files and reads the layout fields instead of deriving
them.
- **README** (`src/memory_chart/README.md`) is the contract: every
field, how to draw a layout, the rules a reader can rely on, and where
to find each metric's value in the analysis database.
- **Tools:** `tools/memory_chart_layout_format.py` (pre-commit
formatter) and `tools/memory_chart_preview.py <arch>` (draws a layout
without a GPU).

Chart changes users will see:
- The boxes in the columns share one width, sized to the widest box;
arrows are sized to fit their labels and values.
- gfx1250 adds instruction cache, scalar data cache, and GL1 latency
metrics; gfx115x shows instruction and data cache bandwidth separately.
- Percent values get a progress bar on every architecture.
- Labels such as the memory type are part of the block title, for
example `DRAM (DDR5/LPDDR5)`.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- `tools/memory_chart_preview.py <arch>` for every architecture, with
full values, no values, and memory bandwidth stalls.
- `rocprof-compute analyze -p <gfx950 workload> -b 3`, with one workload
and with two.

## Test Result

- 1604 tests pass at the tip; pre-commit passes.
- The chart draws for every architecture, and each layout shows every
metric of its memory chart panel and no other.
- With two workloads, the Memory Chart tables keep their titles.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
lamikr pushed a commit that referenced this pull request Oct 27, 2026
…analysis db (#12582)

## Motivation

ROCm Optiq can draw the memory chart from the analysis database alone.
Each workload stores its memory chart layout file unchanged, so the
layout file (#12548) is the only memory chart format.

Bugfix: a GPU whose layout file was skipped as broken no longer stops
the database output.

## Technical Details

- New JSON column `compute_workload.memory_chart_layout_extdata`: the
workload's layout file, or null when its GPU has no layout. Schema
version 2.4.0.
- Layout metrics are panel 3 metric names, unique within panel 3.
Readers find each value and unit in the existing metric tables;
`src/memory_chart/README.md` says how.
- No conversion, metric ids, or format version are stored.

## Issue Tracking

JIRA ID: AIPROFCOMP-683

## Test Plan

- `python -m pytest tests/unit tools/test_memory_chart_*.py` and project
pre-commit.
- On real gfx950 workloads (one and two in a database, and with `-b 2`):
`analyze --output-format db`, then draw the chart from the database with
a reader written only from the README.

## Test Result

- 1606 tests pass at the tip; pre-commit passes.
- The stored column equals the layout file, and every layout metric
finds its value.
- The chart drawn from the database matches the terminal `analyze -b 3`
chart byte for byte.

## Submission Checklist

- [x] Look over the contributing guidelines at
https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants