Repository navigation
feat(rocprofiler-compute): memory chart using json layouts - #12548
Merged
xuchen-amd merged 23 commits intoOct 17, 2026
Merged
xuchen-amd merged 23 commits into
xuchen-amd merged 23 commits into
Conversation
xuchen-amd
force-pushed
the
users/xuchen-amd/memory_chart_json_layouts
branch
2 times, most recently
from
September 30, 2026 15:53
8be6a39 to
4d77f6e
Compare
xuchen-amd
changed the base branch from
rocprofiler-compute-develop
to
users/xuchen-amd/memory_chart_improvements
September 30, 2026 15:53
xuchen-amd
force-pushed
the
users/xuchen-amd/memory_chart_json_layouts
branch
from
September 30, 2026 18:05
4d77f6e to
482a614
Compare
Base automatically changed from
users/xuchen-amd/memory_chart_improvements
to
rocprofiler-compute-develop
October 7, 2026 15:50
xuchen-amd
force-pushed
the
users/xuchen-amd/memory_chart_json_layouts
branch
from
October 7, 2026 21:45
482a614 to
34ad199
Compare
xuchen-amd
force-pushed
the
users/xuchen-amd/memory_chart_json_layouts
branch
from
October 7, 2026 21:59
34ad199 to
289b37f
Compare
Contributor
There was a problem hiding this comment.
🔵 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.
abchoudh-amd
approved these changes
Oct 8, 2026
abchoudh-amd
left a comment
Contributor
There was a problem hiding this comment.
Added some minor comments. Overall looks good.
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>
feizheng10
reviewed
Oct 9, 2026
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
force-pushed
the
users/xuchen-amd/memory_chart_json_layouts
branch
from
October 13, 2026 17:55
2dbcf48 to
c27e27b
Compare
xuchen-amd
marked this pull request as draft
October 14, 2026 21:23
…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
marked this pull request as ready for review
October 15, 2026 21:06
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
src/memory_chart/layouts/*.json): every block states where it goes (column,order,position,parentorhost), every arrow states itsdirection, and each part states how it is drawn (blockstyle, metricbar, arrowstyle).loader.py) checks a layout against the format rules. A broken file is skipped with a warning, so only its architectures lose the chart.render.py) replaces the per-architecturemem_chart_*.pyfiles and reads the layout fields instead of deriving them.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/memory_chart_layout_format.py(pre-commit formatter) andtools/memory_chart_preview.py <arch>(draws a layout without a GPU).Chart changes users will see:
DRAM (DDR5/LPDDR5).Issue Tracking
JIRA ID: AIPROFCOMP-683
Test Plan
python -m pytest tests/unit tools/test_memory_chart_*.pyand 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
Submission Checklist