feat(rcoprofiler-compuite): add missing descriptions of previous counters added to sdk yaml by ywang103-amd · Pull Request #13817 · ROCm/rocm-systems

ywang103-amd · 2026-10-20T16:04:05Z

Motivation

Add descriptions to previous counters whose definition were added to rocprof sdk's counter def yaml file without definition included.

Technical Details

add descriptions in corresponding field in yaml file

Issue Tracking

JIRA ID: AIPROFCOMP-930

Test Plan

Test Result

Submission Checklist

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

- Add `ROCm Compute Profiler 3.11.0 for ROCm 10.3.0` changelog section using the empty subsection template - Bump VERSION 3.10.0 -> 3.11.0 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…es (#12220) ## Motivation Delete the `--tui`, `--gui`, and `--random-port` flags and their presentation layers. Both modes were experimental, unmaintained, and effectively untested. ## Technical Details #### Commit 1. Delete TUI/GUI packages, strip flags and dispatch (128add1) - Delete `src/rocprof_compute_tui/`, `analysis_webui.py`, `gui.py`, `gui_components/`, the Dash assets directory, and TUI unit tests - Strip `--gui`, `--tui`, `--random-port` from the argument parser and the `--experimental` feature list - Remove web_ui/tui branches from mode detection, dispatch, the analysis base class, and the ML-API-trace guard blocks - Remove `Roofline.generate_html_section` and its dash import - Remove `guimode` from `setup_logging_priority` and the Werkzeug suppression block - Remove dead code: `is_gui` parameter from `apply_filters` and `load_table_data`, `tui_style` from 46 YAML configs, `HIDDEN_COLUMNS` and `HIDDEN_COLUMNS_TUI` from `config.py`, `get_agent_dict`, `get_gpuid_dict`, `format_scientific_notation_if_needed`, and their orphaned tests #### Commit 2. Update deps, build, test config, compose files (76ed88d) - Replace dash, dash-bootstrap-components, dash-svg, textual, textual_plotext with explicit plotly and rich pins - Drop TUI ctest registrations, install rule, PyInstaller dash-svg workaround, tui/sci_notion pytest markers, TUI test categories, TUI from conftest allowed-modules, stale `format_yaml.py` and pre-commit-config paths - Drop port 8050 from TheRock compose files #### Commit 3. Remove TUI/GUI documentation and add CHANGELOG (f2beee3) - Remove TUI/GUI doc pages, screenshots, TOC entries, and cross-references - Add CHANGELOG entry under Removed #### Commit 4. Align analyze-mode wording with the CLI-only path (2b777eb) - `analyze/mode.rst` names its two remaining paths, the CLI analyzer and ROCm Optiq, in place of "several ways" - `use.rst` refers to a single analyze mode - Drop the Dash/WebUI precision-selector caveat from the roofline docstring #### Commit 5. Drop the WebUI-only kernel-name filter path (1f9cad1) - Analyze `--kernel` takes int ids only, so the string-name branches in `apply_kernel_filter` and `_resolve_kernel_ids` were unreachable once the WebUI was gone - Remove `Workload.filter_top_n`, which only the WebUI ever wrote - Delete the three tests covering the removed branches #### Commit 6. Remove unreferenced helpers and constants (ae22c22) - `collect_wave_occu_per_cu`, `get_gpu_arch_to_compute_partition_dict`, `string_multiple_lines`, `DEFAULT_THREADS`, `DEFAULT_WORKGROUPS` have no callers - Pre-existing, unrelated to the TUI/GUI removal, but found by the same dead-code sweep ## Issue Tracking JIRA ID: AIPROFCOMP-841 ## Test Plan - `ruff check src tests tools` and `ruff format --check` - `pytest tests/unit` - Confirm no remaining references to `rocprof_compute_tui`, `rocprof_compute_gui`, `analysis_webui`, or the removed helpers ## Test Result - ruff check and format: clean across `src`, `tests`, `tools` - `pytest tests/unit`: 1531 passed ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com>

…rness (#12551) ## Motivation Remove the integration-test baseline metric comparison harness. It has been switched off since February 2024, and it could not work if re-enabled. The 19 `validate(...)` calls at the end of the profiling tests do nothing, but they read as if the tests check metrics against a baseline. This PR removes only test-side code. Product behavior, including `analyze --report-diff`, is unchanged. ## Technical Details #### What the harness was meant to do - `validate()` (`tests/integration/common.py`) ran `baseline_compare_metric()` when `config["METRIC_COMPARE"]` was set. - `baseline_compare_metric()` ran `analyze --path tests/workloads/vcopy/<soc> --path <new run> --report-diff -1`, scraped the console output for flagged metrics, and failed the test when a metric in `METRIC_THRESHOLDS` (about 35 hand-tuned metric IDs) was outside its tolerance. `METRIC_LOGGING` optionally collected the other drifting metrics to help tune the list. - `counter_compare()` was a raw-counter comparison helper with no callers. #### Timeline | Date | Commit | Event | |---|---|---| | 2023-10-04 | `813d5a9ab1` | Result comparison in analyze mode (`--report-diff`) added; the output marker was `DEBUG ERROR: Dataframe diff exceeds …` | | 2024-01-17 | `bec3f337c1` | `METRIC_THRESHOLDS` tuned for low-variance metrics | | 2024-01-30 | `a1371462ba` | Logging refactor changes the marker to `console_warning("Dataframe diff exceeds …")`. The harness still searched for `DEBUG ERROR`, so from here on threshold checks never triggered | | 2024-02-05 / 02-27 | `74299b801d`, `5f741f4632` | `METRIC_COMPARE` set to `False` "for the time being" | | 2024-11-01 | `825440e7ba` | Rename to ROCm Compute Profiler; the harness command becomes `src/rocprof_compute`, but the entry point is `src/rocprof-compute` | | 2026-08-14 | `dae6a4e0b8` (#9732) | Test split moves the helpers into `tests/integration/common.py` unchanged and still disabled | #### State before this PR: three independent breakages 1. Disabled: `METRIC_COMPARE = False`, and nothing sets it to `True`. 2. Wrong executable: it would run the nonexistent `src/rocprof_compute`. 3. Stale parsing: it searches for a marker src hasn't printed since January 2024, so with 1 and 2 fixed it would still pass silently. The threshold metric IDs also predate later panel and metric renumbering. #### Changes - Remove `validate`, `baseline_compare_metric`, `counter_compare`, `METRIC_THRESHOLDS`, `DEFAULT_ABS_DIFF`/`DEFAULT_REL_DIFF`/`MAX_REOCCURING_COUNT`, and the `METRIC_COMPARE`/`METRIC_LOGGING`/`COUNTER_LOGGING` config keys. - Remove the 19 `validate(...)` calls in 10 test files, plus imports and locals that are now unused. The tests' own assertions are unchanged. - Kept: `analyze --report-diff` (its default also drives the `Abs Diff` column when comparing multiple runs) and the `tests/workloads/vcopy` baselines, which other analyze tests use. #### Follow-up for discussion Nothing guards against metric drift between releases today. If the team wants that, a fresh design that compares analyze DB or CSV exports against the baselines, with per-arch thresholds kept in YAML, would be sturdier than reviving console scraping. ## Issue Tracking JIRA ID: ## Test Plan - `ruff check tests` and `ruff format --check tests` - `pytest --collect-only` on every changed integration test file - Run `tests/integration/test_profile_path.py` on MI350 (gfx950), with and without this change ## Test Result - ruff: clean - Collection: 110 tests collected across the 12 changed test files - `test_profile_path.py`: identical results with and without the change (13 passed; 3 failures come from the test environment's native-tool build, which is missing pkg-config, and occur on the base commit too) ## 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>

- argparser.py: keep the --gui/--tui removal and develop's _skills_note() - .config_hashes.json: regenerated with hash_manager.py from the merged YAMLs Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…ls (#12050) ## Motivation The repo has no C++ standard today, so reviewers argue the same points on every C++ PR and agents make up their own rules each session. Python has a standard and `AGENTS.md` points at it. The rocprofiler-systems-skills repo already has C++ skills that someone maintains. Copying and editing them is cheaper than writing our own, and it puts both profiler projects on the same style. ## Technical Details The design record is `docs/design/lld-cpp-coding-guidelines.md`. This PR implements it. - Split the upstream umbrella skill by topic under `.ai/rules/cpp/`. One flat set of files, each short enough to read in one sitting and to cite in a review comment. Each file owns its subject. `CPP_CODING_STYLE.md` at the project root is the only index. - Keep the C++17 baseline everywhere. - Add `callback-boundaries.md`, which has no upstream equivalent. Every library we ship runs inside a rocprofiler-sdk, torch, or Python callback. That shapes threading, error propagation, and process-lifetime state together, so they live in one file. No exception may escape into a host callback. - Allow two forms of process-lifetime state. The choice turns on whether the host tears down after our static destructors, which is why `rocprofiler_compute_tool.cpp` leaks its globals on purpose. - Cut naming to one rule, types are PascalCase, so new types are consistent without renaming anything. - Drop the policy-based DI skill. Our mocks derive from virtual interfaces and template policies would break them. - Keep design patterns as a topic file, trimmed, calling out the two shapes other rules depend on: Adapter for the test seams, Strategy for branch chains. The C++17 constexpr detail lives in `core.md`, next to the rule that needs it. - Wire it into `AGENTS.md`, a Cursor rule scoped to C++ and CMake globs, and the style reference table in `CONTRIBUTING.md`. ## Issue Tracking JIRA ID: N/A ## Test Plan - [x] Documentation only, no code changes. - [x] Verified every relative link resolves. - [x] Verified every topic file has a row in the index. - [x] Ran pre-commit with the project config. ## Test Result - All relative links resolve and every topic file is indexed. Pre-commit passes. ## 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 (1M context) <noreply@anthropic.com> Co-authored-by: fei.zheng <fei.zheng@amd.com> Co-authored-by: Grok 4.7 <noreply@cursor.com> Co-authored-by: Cursor <cursoragent@cursor.com>

…ategories (#12554) ## Motivation Two test files never run in CI: `test_mem_chart_common.py` has no CTest registration, and `test_profile_membw` is registered but listed in no test category. CI selects tests by category label, so both were silently skipped. This PR registers them. ## Technical Details - Add `add_test(test_mem_chart_common)` next to the other mem chart tests, and list it in every category in `tests/test_categories.yaml` and in the coverage `ALL_TEST_NAMES` - Add `test_profile_membw` to the standard, comprehensive, and full categories, matching `test_profile_path`. The test skips itself on anything but MI350 - Add the already-registered `test_per_kernel_isa_export` to `ALL_TEST_NAMES` so the coverage report waits for it ## Issue Tracking JIRA ID: ## Test Plan - `pytest tests/unit/utils/test_mem_chart_common.py` - Run `shared/ctest/parse_ctest_categories.py` on the updated YAML and confirm it labels both tests - Run `tests/integration/test_profile_membw.py` on MI350 (gfx950) - gersemi on `CMakeLists.txt` ## Test Result - `test_mem_chart_common.py`: 51 passed - Category parser: both tests labeled in every intended category - `test_profile_membw.py` on MI350: 1 passed (2m10s) - gersemi: passed ## 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>

## Motivation The analysis database stores workload-level roofline aggregates that the analysis flow does not use. Removing this table reduces the persisted schema while retaining per-kernel roofline data. ## Technical Details - Remove the workload roofline ORM model, its workload relationship, and the database insertion path. - Keep per-kernel roofline calculations and have the analysis flow return only kernel-level results. - Bump the analysis database schema version to 2.3.1 and regenerate the schema diagram. ## JIRA ID JIRA ID: AIPROFCOMP-910 ## Test Plan - [x] Run pytest tests/unit/rocprof_compute_analyze/test_analysis_db.py - [x] Run pytest tests/integration/test_profile_misc.py -k test_analyze_rocpd ## Test Result - [x] Unit and integration tests pass locally. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. --------- Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…detach unit test (#12660) ## Motivation test_live_attach_detach_pc_sampling was failing on MI455X versions due to hw support- this is expected that not all MI455X setups will be able to run pc sampling, so we expect failures. The attach detach runs pc sampling but does not have the same checks as the pc_sampling-specific test cases, which will check for specific ERROR messages indicating hw does not support the option. We should be avoiding this corner case on the MI455X setup by using the proper pc sampling support checks that all other pc sampling tests utilize. Changes in this PR include moving some of the helpers to a more public interface space to use in both test_pc_sampling and test_profile_live_attach_detach files, and adding an output capture to read the error message and properly discard the failure/pass gracefully. ## Technical Details Promoted is_pc_sampling_not_supported and skip_if_pc_sampling_unsupported from private helpers in test_pc_sampling.py to public functions in integration_common, and wired test_live_attach_detach_pc_sampling to use them so it skips gracefully instead of failing on unsupported hardware. ## Issue Tracking AIPROFCOMP-915 ## Test Plan Ctest suite + individual runs of the affected tests, verify multiple archs. ## Test Result MI455X: Passing all ctest MI350X: `ctest --output-on-failure -R pc_sampling` ``` 1/4 Test #66: test_pc_sampling ................. Passed 160.96 sec 2/4 Test #67: test_pc_sampling_analysis ........ Passed 6.17 sec 3/4 Test #68: test_pc_sampling_analyze_cli ..... Passed 15.71 sec 4/4 Test #77: test_pc_sampling_profile ......... Passed 4.17 sec ``` `ctest --output-on-failure -R attach` `1/1 Test #14: test_profile_live_attach_detach ... Passed 63.97 sec ` - [X] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. --------- Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>

- Resolve conflicts from #12817 in favor of rocprofiler-compute-develop, which already removed the --gui and --tui analyze modes (#12220) - Keep the 3.10.0 deprecation note in CHANGELOG Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

## Motivation The memory chart had several usability issues: - Bandwidth values used mixed units (TB/s, GB/s, MB/s, B/s), making cross-level comparison difficult - The "Kernel" panel showed no hardware metrics - HBM/Remote Traffic labels implied bandwidth but displayed percentages - The VL1D cache panel was missing the coalescence rate metric - xGMI and MALL blocks had no connectivity arrows, hiding how Data Fabric traffic is routed ## Technical Details **Uniform BW formatting:** All bandwidth values now display as fixed GB/s with 3 decimal places. **Compute Units panel (gfx9):** Renamed "Kernel" to "Compute Units" and populated with wave occupancy (% of the maximum waves per CU), vGPRs, sGPRs, scratch (KB per wave), LDS allocation (KB), and workgroups per active CU. The stats list is built by the shared `build_cu_stats()` helper. Renamed `build_kernel_panel()` to `build_cu_panel()` in shared code. **WGPs panel (gfx115x and gfx1250):** Renamed "Kernel" to "WGPs" (new `title` argument on `build_cu_panel()`) and populated with the same resource allocation stats. The stats live in a new "Workgroup Processors (WGPs)" metric table (3.10 on gfx115x, 3.9 on gfx1250), so existing 3.1.N IDs are unchanged. Wave occupancy is reported as a percent of the maximum waves per WGP, and workgroups per WGP: - gfx115x: rocminfo's "Compute Unit" counts real CUs (2 SIMDs per CU), so the per-WGP limit is `2 * $max_waves_per_cu` and the WGP count is `$cu_per_gpu / 2`. The occupancy formula now divides by `SQ_BUSY_CYCLES_sum` instead of `SQ_BUSY_CYCLES_avr`. SQ has one instance per WGP, so the old formula produced a GPU-wide count. - gfx1250: rocminfo's "Compute Unit" counts WGPs (4 SIMDs), so `cu_per_gpu` already gives a per-WGP value. **gfx1250 Wavefront Occupancy timebase:** Unchanged from develop (`$GRBM_GUI_ACTIVE_PER_XCD`). Validating the gfx1250 GRBM timebase on hardware is tracked in a separate ticket. **VL1D coalescence rate (gfx9):** Added the existing `VL1 Coalesce` YAML metric to the VL1D cache panel. **DF to MALL edges (gfx9):** Added bandwidth arrows between Data Fabric and MALL. gfx940-942 use the new `Estimated HBM Read BW` and `Estimated HBM Write and Atomic BW` metrics (64B-per-request approximation); gfx950 uses `HBM Read BW` and the new `HBM Write and Atomic BW`. A measured zero renders as `0.000 GB/s`, not `N/A`. **xGMI block (gfx9):** Now shown for gfx908, gfx90a, and gfx940-942 (panel only, no BW counters). Previously only visible on gfx950. **YAML cleanup:** Removed the HBM/remote traffic percentage metrics (gfx908-942) and other metrics not rendered in the memory chart. The remaining CDNA table 3.1 metrics are renumbered, so `3.1.N` IDs change on gfx908-gfx950. Removed the now-stale metric IDs from `profiling_counter_grouping_policy.yaml`. **Metric description propagation:** Added the CDNA panel ID 301 mapping and the gfx115x/gfx1250 WGPs table mappings to `metric_description_manager.py`, and the WGPs table to the gfx11/gfx12 config templates. Every CDNA memory chart metric now has a `unit`, and the table header carries a unit column so units reach the CSV/DB output. Descriptions were checked against their formulas (for example, `sL1D Hit` is a hit-rate %), "for this kernel" was dropped since values are averaged over the analyzed dispatches, and the rst descriptions link to the related docs sections. Regenerated per-arch descriptions, docs metric YAMLs, and config hashes. **Cleanup:** Removed the unused `format_bw_human_readable()`, simplified `format_value()`, and shared the IO panel grid code between the xGMI/PCIe builders in `mem_chart_gfx9.py`. **Docs:** Replaced the outdated `mem_chart.png` screenshot (old legacy layout) with inline CLI text output of the new Rich-based chart. Updated changelog with all user-visible changes. ## Issue Tracking JIRA ID: AIPROFCOMP-849 ## Test Plan - Render the gfx9 chart for gfx908, gfx942, and gfx950: `PYTHONPATH=src python -m utils.mem_chart_gfx9 --arch <arch>` - Render the gfx115x and gfx1250 charts: `PYTHONPATH=src python -m utils.mem_chart_gfx11` and `python -m utils.mem_chart_gfx1250` - Analyze the recorded vcopy workloads: `python src/rocprof-compute analyze -p tests/workloads/vcopy/<MI300X_A1|MI350|RDNA35_HALO> -b 3` - Run the unit tests: `pytest tests/unit` - Validate metric configs: `python tools/config_management/master_config_workflow_script.py --validate-only` and `python tools/config_management/hash_checker.py` ## Test Result - [x] gfx908, gfx942, and gfx950 charts render with the Compute Units panel, GB/s values, and MALL/xGMI blocks - [x] gfx115x and gfx1250 charts render the WGPs panel with Wave Occ % and Workgroups/WGP - [x] gfx1151 `vcopy` recorded workload shows Wave Occ 91.0% (about 58 of 64 waves per WGP); the old formula showed ~936 waves - [x] Unit tests pass (1523 passed) - [x] Metric config validation and hash check pass (0 errors across 8 architectures) - [ ] gfx1250 occupancy not validated on hardware (no cached gfx1250 workload; GRBM timebase check tracked separately) - Note: the MI300X_A1 cached workload records identical start and end timestamps (zero duration), so every bandwidth metric is `N/A` there, including System Speed-of-Light 2.1. It also has no `SQ_LEVEL_WAVES_ACCUM` data, so Wave Occ is `N/A`. MI350 shows the full chart. ### Memory chart output (`analyze -b 3`) <details><summary>MI300X_A1 (gfx942), cached vcopy</summary> ``` 3. Memory Chart (Normalization: per_kernel) ╭──────────────────────╮ │ xGMI (to Peer GPU) │ ╰──────────────────────╯ || |------------------------------------------------- GPU (XCD) --------------------------------------------------|------------------------------------------ Fabric / Memory ------------------------------------------| ╭── Compute Units ───╮Non-buffer Request╭─────── VL1D ───────╮Read BW ╭──────── L2 ────────╮ ╭─── Data Fabric ────╮ ╭─────── MALL ───────╮╭─────── UMC ────────╮╭─────── HBM ────────╮ │ Wave Occ N/A │Read : 1.64e+04 │ Hit 62.0% │N/A │ Hit 33.0% │ │ │ │ ││ ││ │ │ vGPRs 4.0 │<--------------- │ ██████░░░░ │<-----------│ ███░░░░░░░ │ │ │ │ ││ ││ │ │ sGPRs 16.0 │Write : 1.64e+04 │ │ │ │ │ │ │ ││ ││ │ │ Scratch/Wave │---------------> │ Coalesce 25.0% │Write BW │ │ │ │ │ ││ ││ │ │ 0.000 KB │Atomic : 0 │ ██░░░░░░░░ │N/A │ │ │ │ │ ││ ││ │ │ LDS Alloc 0.0 KB │<--------------> │ │----------->│ │ │ │ │ ││ ││ │ │ Workgroups/CU │Buffer Request │ │ │ │ │ │ │ ││ ││ │ │ 178.1 │Read : 0 │ │Atomic BW │ │ │ │ │ ││ ││ │ │ │<--------------- │ │N/A │ │ │ │ │ ││ ││ │ │ │Write : 0 │ │<---------->│ │ │ │ │ ││ ││ │ │ │---------------> │ │ │ │ │ │ │ ││ ││ │ │ │Atomic : 0 │ │ │ │ │ │ │ ││ ││ │ │ │<--------------> │ │ │ │Read BW │ │Read BW │ ││ ││ │ │ │ │ │ │ │N/A │ │N/A │ ││ ││ │ │ │ ╰────────────────────╯ │ │<----------- │ │<----------- │ ││ ││ │ │ │Instr : 0 ╭─────── LDS ────────╮ │ │ │ │ │ ││ ││ │ │ │<--------------> │ Util 0.0% │ │ │Write/Atomic BW│ │Write/Atomic BW│ ││ ││ │ │ │ │ ░░░░░░░░░░ │ │ │N/A │ │N/A │ ││ ││ │ │ │ │ │ │ │-----------> │ │-----------> │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ ╰────────────────────╯ │ │ │ │ │ ││ ││ │ │ │SMEM ╭─────── sL1D ───────╮Read BW │ │ │ │ │ ││ ││ │ │ │Read : 6.55e+04 │ Hit 92.0% │N/A │ │ │ │ │ ││ ││ │ │ │<--------------- │ █████████░ │<-----------│ │ │ │ │ ││ ││ │ │ │ ╰────────────────────╯ │ │ │ │ │ ││ ││ │ │ │ICACHE ╭─────── L1I ────────╮Read BW │ │ │ │ │ ││ ││ │ │ │Read : 6.55e+04 │ Hit 98.0% │N/A │ │ │ │ │ ││ ││ │ │ │<--------------- │ █████████░ │<-----------│ │ │ │ │ ││ ││ │ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯╰────────────────────╯╰────────────────────╯ Legend: <---- Read ----> Write <---> Atomic █ Util █ Hit% ``` </details> <details><summary>MI350 (gfx950), cached vcopy</summary> ``` 3. Memory Chart (Normalization: per_kernel) ╭──────────────────────╮ │ xGMI (to Peer GPU) │ ╰──────────────────────╯ || Read BW 0.000 GB/s || Write BW 0.000 GB/s || Atomic BW 0.000 GB/s |-------------------------------------------------- GPU (XCD) --------------------------------------------------|------------------------------------------ Fabric / Memory ------------------------------------------| ╭── Compute Units ───╮Non-buffer Request╭─────── VL1D ───────╮Read BW ╭──────── L2 ────────╮ ╭─── Data Fabric ────╮ ╭─────── MALL ───────╮╭─────── UMC ────────╮╭─────── HBM ────────╮ │ Wave Occ 75.1% │Read : 1.64e+04 │ Hit 62.0% │1513.097 GB/s│ Hit 34.0% │ │ │ │ ││ ││ Read BW │ │ vGPRs 4.0 │<--------------- │ ██████░░░░ │<----------- │ ███░░░░░░░ │ │ │ │ ││ ││ 1513.882 GB/s │ │ sGPRs 16.0 │Write : 1.64e+04 │ │ │ │ │ │ │ ││ ││ │ │ Scratch/Wave │---------------> │ Coalesce 25.0% │Write BW │ │ │ │ │ ││ ││ Write BW │ │ 0.000 KB │Atomic : 0 │ ██░░░░░░░░ │1513.097 GB/s│ │ │ │ │ ││ ││ 1513.097 GB/s │ │ LDS Alloc 0.0 KB │<--------------> │ │-----------> │ │ │ │ │ ││ ││ │ │ Workgroups/CU 62.1 │Buffer Request │ │ │ │ │ │ │ ││ ││ Atomic BW │ │ │Read : 0 │ │Atomic BW │ │ │ │ │ ││ ││ 0.000 GB/s │ │ │<--------------- │ │0.000 GB/s │ │ │ │ │ ││ ││ │ │ │Write : 0 │ │<----------> │ │ │ │ │ ││ ││ │ │ │---------------> │ │ │ │ │ │ │ ││ ││ │ │ │Atomic : 0 │ │ │ │ │ │ │ ││ ││ │ │ │<--------------> │ │ │ │Read BW │ │Read BW │ ││ ││ │ │ │ │ │ │ │1513.882 GB/s │ │1513.882 GB/s │ ││ ││ │ │ │ ╰────────────────────╯ │ │<----------- │ │<----------- │ ││ ││ │ │ │Read : 0 ╭─────── LDS ────────╮ │ │ │ │ │ ││ ││ │ │ │<--------------- │ Util 0.0% │ │ │Write/Atomic BW│ │Write/Atomic BW│ ││ ││ │ │ │Write : 0 │ ░░░░░░░░░░ │ │ │1513.097 GB/s │ │1513.097 GB/s │ ││ ││ │ │ │---------------> │ │ │ │-----------> │ │-----------> │ ││ ││ │ │ │Atomic : 0 │ │ │ │ │ │ │ ││ ││ │ │ │<--------------> │ │ │ │ │ │ │ ││ ││ │ │ │Instr : 0 │ │ │ │ │ │ │ ││ ││ │ │ │<--------------> │ │ │ │ │ │ │ ││ ││ │ │ │ │ │ │ │ │ │ │ ││ ││ │ │ │ ╰────────────────────╯ │ │ │ │ │ ││ ││ │ │ │SMEM ╭─────── sL1D ───────╮Read BW │ │ │ │ │ ││ ││ │ │ │Read : 6.55e+04 │ Hit 93.0% │1.674 GB/s │ │ │ │ │ ││ ││ │ │ │<--------------- │ █████████░ │<----------- │ │ │ │ │ ││ ││ │ │ │ ╰────────────────────╯ │ │ │ │ │ ││ ││ │ │ │ICACHE ╭─────── L1I ────────╮Read BW │ │ │ │ │ ││ ││ │ │ │Read : 6.55e+04 │ Hit 93.0% │6.696 GB/s │ │ │ │ │ ││ ││ │ │ │<--------------- │ █████████░ │<----------- │ │ │ │ │ ││ ││ │ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯ ╰────────────────────╯╰────────────────────╯╰────────────────────╯ || Read BW 0.000 GB/s || Write BW 0.000 GB/s || Atomic BW 0.000 GB/s ╭────────────────────────────────────────────╮ │ PCIe (to CPU or Non-xGMI connected GPU) │ ╰────────────────────────────────────────────╯ Legend: <---- Read ----> Write <---> Atomic █ Util █ Hit% ``` </details> <details><summary>RDNA35_HALO (gfx1151), cached vcopy</summary> ``` 3. Memory Chart (Normalization: per_kernel) |---------------------------------------------------------------------- GPU -----------------------------------------------------------------------|----- System Memory ------| ╭─────── WGPs ───────╮ Request ╭────── LDS ───────╮ ╭─ GL1 Cache ──╮ ╭─ GL2 Cache ──╮ ╭──── GCEA ────╮ ╭──── DRAM ────╮ │ Wave Occ 91.0% │LDS : 0 │ Util 0.0% │ │ Util 79.7% │ │ Util 79.8% │ │ SysArb Util │ │ DDR5/LPDDR5 │ │ vGPRs 8.0 │-------------------- │ ░░░░░░░░░░ │ │ ███████░░░ │ │ ███████░░░ │ │ 22.9% │ │ │ │ sGPRs 128.0 │ │ │ │ │ │ │ │ ██░░░░░░░░ │ │ Total: │ │ Scratch/Wave │ │ BW 0.000 GB/s │ │ Hit Rate │ │ Hit Rate │ │ │ │ 357.721 GB/s │ │ 0.000 KB │ │ │ │ 0.0% │ │ 33.3% │ │ SysArb Stall │ │ │ │ LDS Alloc 0.0 KB │ │ Bank Conflict │ │ ░░░░░░░░░░ │ │ ███░░░░░░░ │ │ 18.5% │ │ │ │ Workgroups/WGP │ │ N/A │ │ │ │ │ │ │ │ │ │ 256.0 │ │ │ │ GL2 Stall │ │ │ │ │ │ │ │ │ ╰──────────────────╯ │ 1.0% │ │ │ │ │ │ │ │ │Read : 0 ╭─ GL0 (TCP Cache)─╮Read BW │ │ │ │ │ │ │ │ │ │<------------------- │ Hit Rate N/A │166.310 GB/s│ │Read BW │ │Read BW │ │Read BW │ │ │ │Write : 0 │ ░░░░░░░░░░ │<------- │ │185.212 GB/s│ │185.207 GB/s│ │185.297 GB/s│ │ │ │-------------------> │ │ │ │<------- │ │<------- │ │<------- │ │ │ │ │ BW 0.000 GB/s │Write BW │ │ │ │ │ │ │ │ │ │ │ │0.000 GB/s │ │Write BW │ │Write BW │ │Write BW │ │ │ │ │ │-------> │ │185.186 GB/s│ │173.257 GB/s│ │172.425 GB/s│ │ │ │ │ │ │ │-------> │ │-------> │ │-------> │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ╰──────────────────╯ │ │ │ │ │ │ │ │ │ │ICache Read: 128 ╭────── SQC ───────╮Read BW │ │ │ │ │ │ │ │ │ │<------------------- │ ICache Hit Rate │0.060 GB/s │ │ │ │ │ │ │ │ │ │DCache Read: 1.33e+05│ 0.0% │<------- │ │ │ │ │ │ │ │ │ │<------------------- │ ░░░░░░░░░░ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ DCache Hit Rate │ │ │ │ │ │ │ │ │ │ │ │ 100.0% │ │ │ │ │ │ │ │ │ │ │ │ █████████░ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ╰────────────────────╯ ╰──────────────────╯ ╰──────────────╯ ╰──────────────╯ ╰──────────────╯ ╰──────────────╯ Legend: <---- Read ----> Write █ Util █ Hit% █ Stall ``` </details> <details><summary>gfx1250, synthetic sample metrics (`python -m utils.mem_chart_gfx1250`)</summary> ``` 3. Memory Chart (Normalization: per_kernel) |------------------------------------------- XCD -------------------------------------------|---------------------------------- AID ----------------------------------| ╭─────── WGPs ───────╮ ╭────────── TCP ──────────╮ ╭──── GL1 ────╮Read BW ╭─── GLARB ───╮Read BW ╭──── GL2 ────╮Read BW ╭─── EA/DF ───╮DRAM Read ╭──── HBM ─────╮ │ Wave Occ 50.0% │ Request │ TXA/TXD/TDM │ │ GL1A Util │412.800 GB/s│ GLARBA Util │380.500 GB/s│ GL2A Util │485.600 GB/s│ EA Util │512.000 GB/s│ Total │ │ vGPRs 64.0 │ │ ╭──────── LDS ────────╮ │ │ 65.2% │<--------- │ 52.3% │<--------- │ 74.2% │<--------- │ 65.8% │<--------- │ 896.000 GB/s │ │ sGPRs 32.0 │ │ │ │ │ │ ██████░░░░ │ │ █████░░░░░ │ │ ███████░░░ │ │ ██████░░░░ │ │ │ │ Scratch/Wave │Load : 1.25e+03 │ │ Util 65.8% │ │ │ │Write BW │ │Write BW │ │Write BW │ │DRAM Write │ │ │ 0.000 KB │<----------------- │ │ Bank Conflict 5.2% │ │ │ GL1C Util │156.300 GB/s│ GLARBC Util │142.800 GB/s│ GL2C Hit │362.400 GB/s│ Stall 15.2% │384.000 GB/s│ │ │ LDS Alloc 32.0 KB │ │ │ │ │ │ 72.8% │---------> │ 58.6% │---------> │ 82.5% │---------> │ █░░░░░░░░░ │---------> │ │ │ Workgroups/WGP 2.0 │Store : 625 │ │ Load BW 268.700 │ │Async Load │ ███████░░░ │ │ █████░░░░░ │ │ ████████░░ │ │ │ │ │ │ │-----------------> │ │ GB/s │ │50.000 GB/s │ │ │ │Atomic BW │ │Atomic BW │ │ │ │ │ │ │ │ Store BW 134.200 │ │<--------- │ Buf Stall │ │ Buf Stall │28.600 GB/s │ │25.200 GB/s │ │ │ │ │ │Atomic : 1.25e+03 │ │ GB/s │ │ │ 12.5% │ │ 12.4% │<--------> │ │<--------> │ │ │ │ │ │<----------------> │ │ Atomic BW 16.000 │ │Async Store │ █░░░░░░░░░ │ │ █░░░░░░░░░ │ │ │ │ │ │ │ │ │ │ │ GB/s │ │25.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │Async Ld: 250 │ ╰─────────────────────╯ │---------> │ │ │ │ │ │ │ │ │ │ │ │<----------------- │ ╭──────── GL0 ────────╮ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Util 72.4% │ │TDM Load │ │ │ │ │ │ │ │ │ │ │ │Async St: 1.00e+03 │ │ Hit Rate 87.2% │ │80.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │-----------------> │ │ │ │<--------- │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │TDM Ld : 5.00e+03 │ │ │ │TDM Store │ │ │ │ │ │ │ │ │ │ │ │<----------------- │ │ │ │40.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │ │ ╰─────────────────────╯ │---------> │ │ │ │ │ │ │ │ │ │ │ │TDM St : 2.50e+03 │ │ │ │ │ │ │ │ │ │ │ │ │ │-----------------> │ │Read BW │ │ │ │ │ │ │ │ │ │ │ │ │ │412.800 GB/s│ │ │ │ │ │ │ │ │ │ │ │ │ │<--------- │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Write BW │ │ │ │ │ │ │ │ │ │ │ │ │ │206.400 GB/s│ │ │ │ │ │ │ │ │ │ │ │ │ │---------> │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │Read : 8.75e+05 │ │Atomic BW │ │ │ │ │ │ │ │ │ │ │ │<----------------- │ │16.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │ │ │<--------> │ │ │ │ │ │ │ │ │ │ │ │Write : 3.75e+05 │ │ │ │ │ │ │ │ │ │ │ │ │ │-----------------> │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ╰──────────────╯ │ │Atomic : 6.25e+04 │ │ │ │ │ │ │ │ │ │ │ │<----------------> │ │Read BW │ │ │ │ │ │ │ │ IO Read ╭───── IO ─────╮ │ │ │ │57.600 GB/s │ │ │ │ │ │ │ │ 32.000 GB/s │ PCIe and │ │ │ │ │<--------- │ │ │ │ │ │ │ │<-------------------------- │ other I/O │ │ │ │ │Read BW │ │ │ │ │ │ │ │ │ │ │ │ ╰─────────────────────────╯28.800 GB/s │ │ │ │ │ │ │ │ IO Write │ │ │ │ ╭────────── SQC ──────────╮<--------- │ │ │ │ │ │ │ │ 24.000 GB/s │ │ │ │ │ ╭─ Instruction Cache ─╮ │ │ │ │ │ │ │ │ │--------------------------> │ │ │ │ICACHE : 450 │ │ Hit Rate 98.5% │ │ │ │ │ │ │ │ │ │ ╰──────────────╯ │ │<----------------- │ │ │ │ │ │ │ │ │ │ │ │ HDM Read ╭──── HDM ─────╮ │ │ │ │ │ │ │ │ │ │ │ │ │ │ 128.000 GB/s │ CXL │ │ │ │ ╰─────────────────────╯ │ │ │ │ │ │ │ │ │<-------------------------- │ │ │ │ │ ╭─ Scalar Data Cache ─╮ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Hit Rate 95.3% │ │ │ │ │ │ │ │ │ │ HDM Write │ │ │ │SMEM : 225 │ │ │ │ │ │ │ │ │ │ │ │ 96.000 GB/s │ │ │ │<----------------- │ │ │ │ │ │ │ │ │ │ │ │--------------------------> │ │ │ │ │ ╰─────────────────────╯ │ │ │ │ │ │ │ │ │ ╰──────────────╯ │ │ │ │ │ │ │ │ │ │ │ │ GMI Read ╭──── GMI ─────╮ │ │ │ │ │ │ │ │ │ │ │ │ 256.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │ │ │<-------------------------- │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ GMI Write │ │ │ │ ╰─────────────────────────╯ │ │ │ │ │ │ │ │ 192.000 GB/s │ │ │ │ │ │ │ │ │ │ │ │--------------------------> │ │ │ │ │ │ │ │ │ │ │ │ ╰──────────────╯ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ╰────────────────────╯ ╰─────────────╯ ╰─────────────╯ ╰─────────────╯ ╰─────────────╯ Legend: <---- Read ----> Write <---> Atomic █ Util █ Hit% █ Stall ``` </details> ## 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 <noreply@anthropic.com>

) ## Motivation The memory chart HTML work needs reusable row filters, terminal column choices, and memory bandwidth summaries. This refactor preserves the existing analyze output. ## Technical Details - Expose GPU and dispatch filtering for chart views while preserving CLI kernel-scoped dispatch validation. - Extract hidden-column resolution and memory bandwidth status text from terminal rendering. - Separate memory bandwidth tree loading from dataframe evaluation while keeping its existing warnings. - Cover the extracted parser, terminal, summary, and engine behavior with unit tests. ## JIRA ID JIRA ID: AIPROFCOMP-868 ## Test Plan - [x] Run ctest for the parser, TTY, and memory bandwidth analysis targets. ## Test Result - [x] ctest for the parser, TTY, and memory bandwidth analysis targets pass ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

## Motivation  Prevent a crash when --list-stats is used with CSV or DB output. ## Technical Details  - Reject this unsupported combination during option sanitization with a clear error. - Add regression tests and update help text and documentation. ## Issue Tracking    JIRA ID: ROCM-29368 ## Test Plan  - Verify --list-stats with CSV/DB output is rejected clearly. - Confirm supported text output and regular CSV/DB exports still work. - Verify the revised fix on MI325X. ## Test Result  - Relevant unit and integration tests passed. - All seven MI325X analysis checks passed, covering text output, rejection of unsupported CSV/DB combinations, and normal CSV/DB exports. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. --------- Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…ter registry (#11804) ## Motivation Give the native tool one place that owns output generation, so a collection service produces an artifact by registering a writer rather than owning a flush path of its own. ## Technical Details - Add `OutputRegistry`: writers register with it, and one `generate_all` call at shutdown writes everything. - A writer that throws is logged and skipped, so one failure cannot lose the other writers' data. - Counter CSV and PC sampling become registered writers; kernel-id filtering moves into the counters writer so the registry stays generic. - `tool_data` holds the PC sampling feature by `shared_ptr`, so the collector and the registered writer are the same object. - `test_knobs` resets the registry between tests. ## Issue Tracking JIRA ID: AIPROFCOMP-852 ## Test Plan - [x] `cmake --build <build> --target test-rocprofiler-compute-tool && ./bin/test-rocprofiler-compute-tool` - [x] `pre-commit run --config projects/rocprofiler-compute/.pre-commit-config.yaml --files <changed>` ## Test Result - Native tool gtests pass locally on gfx950, including the new registry cases: every writer runs once, a throwing writer does not stop the others, and a reset registry has no writers left to call. - Pre-commit hooks pass on the changed files. ## 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 (1M context) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

… tool (#11982) ## Motivation Every field describing a kernel dispatch has come from rocprofv3's tool backend by way of the rocpd counters_collection view: kernel name, launch dimensions, register and memory footprint, timestamps. This makes the native tool the source of that data. Stacked on #11804. Retarget to `rocprofiler-compute-develop` once that merges. Depends on ROCm/TheRock#8606 (RPATH origin for `test-csv`), which is merged and included in the TheRock ref pinned on `rocprofiler-compute-develop`. ## Technical Details - The tool writes two new per-process artifacts alongside the counter CSV: the dispatches, and the kernel symbols. Both go through the output registry. - Kernel properties live in their own artifact rather than on every dispatch row. On a million dispatches over fifty kernels, folding them in costs 1.49x the gzip size and 2.4x the analyze-side read for data that repeats. - Kernel names are demangled with any trailing ".kd" removed, matching what rocprofv3 writes under its defaults. The kernel filter path shares the helper, which fixes the same missing strip in --kernel matching. - Dispatch data comes from kernel dispatch tracing, always on and independent of counter collection. Tracing alone does not serialize kernels. - The counter CSV drops gpu_id, kernel_id and lds_per_workgroup, which the dispatch CSV carries. - Profile mode moves the per-process files into the workload directory and merges nothing. Analyze joins them on (pid, dispatch_id) and (pid, kernel_id), sums counter instances, and reassigns dispatch and kernel ids per counter set, in launch order (bugfix). - GPU_ID carries the agent handle where the rocpd path carries the node id. Analyze dense-ranks it, so a single-process run produces the same report. Handles differ between processes for the same GPU; #12402 writes the node id instead. - The rocpd path stays in place and still runs, unused by this path. ## Issue Tracking JIRA ID: AIPROFCOMP-852 ## Test Plan - [x] `cmake --build <build> --target test-rocprofiler-compute-tool && ./bin/test-rocprofiler-compute-tool` - [x] `ctest -R '^test-csv$'` - [x] `pytest tests/unit` - [x] Profile one run and compare the analyze inputs built down each path - [x] `pre-commit run --config projects/rocprofiler-compute/.pre-commit-config.yaml --files <changed>` ## Test Result - Native tool gtests and the Python unit suite pass locally on gfx950. - For a single profile run, pmc_perf.csv, pmc_dispatch_info.csv and pmc_kernel_top.csv built from the native artifacts match the rocpd-derived ones on a plain counter run, kernel name filtering, a kernel iteration range, iteration multiplexing, a two-rank MPI run, and the multiprocess rocflop workload. GPU_ID and GUID are excluded from that comparison: see above for GPU_ID, and GUID carries the pid rather than a per-run uuid. - test_analyze_workloads passes unchanged on the checked-in workloads. ## 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 (1M context) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…2402) ## Motivation The native tool reports the GPU agents it saw, so it no longer needs rocpd or rocprofv3's JSON to know which devices took part in a run. Stacked on #11982. Retarget to `rocprofiler-compute-develop` once that merges. ## Technical Details - The tool queries the GPU agents once when HSA loads and writes them to a per-process agents CSV: node id, gfx arch, product name. - The dispatch CSV's gpu_id carries the agent's node id, the value rocpd writes. The SDK offsets agent handles randomly per process, so handles are not comparable across processes. - Profile mode keeps the agents CSV beside the other native artifacts, and analyze requires it. - Analyze numbers GPUs from 0 in node order over every agent, so a GPU that ran no dispatch keeps its id. rocpd workloads still number only the GPUs that ran. ## Issue Tracking JIRA ID: AIPROFCOMP-852 ## Test Plan - [x] `cmake --build <build> --target test-rocprofiler-compute-tool && ./bin/test-rocprofiler-compute-tool` - [x] `pytest tests/unit` - [x] Profile a two-rank MPI run on one GPU and compare the analyze inputs built down each path - [x] `pre-commit run --config projects/rocprofiler-compute/.pre-commit-config.yaml --files <changed>` ## Test Result - Native tool gtests and the Python unit suite pass locally on gfx950. - On a two-rank run on one gfx950, pmc_perf.csv, pmc_dispatch_info.csv and pmc_kernel_top.csv built from the native artifacts match the rocpd-derived ones for each rank, GPU_ID included. - End to end on gfx950 for counter collection, roofline, PC sampling and a two-process run: on the same profile run, analyze's counter frame and its stdout, txt, csv and db output match what rocprofiler-compute-develop's code produces. ## 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>

…13387) ## Motivation `skills/run_evals.py` aborts partway through both routing and behavioral runs, so no PASS/FAIL summary is printed. This makes both modes run to completion and grade against a real sample application. Bugfix: the run no longer aborts on `permission_denied` events or long judge prompts. ## Technical Details - Skip stream-json events whose `message` or `input` is not a dict. - Send the judge prompt on stdin, and ask it only whether the claim holds. - Fail a case when `claude` exits non-zero. - Run the agent and judge with `--setting-sources project,local`. - Copy `sample/` into each workspace. Positive cases that need an application name it with a new `sample` key, which behavioral mode adds to the prompt. Routing prompts are unchanged. - Behavioral mode uses `--permission-mode bypassPermissions` so the agent can build and profile the sample. ## Issue Tracking JIRA ID: AIPROFCOMP-931 ## Test Plan - `./skills/run_evals.py --list` - `./skills/run_evals.py` across all skills - `./skills/run_evals.py --mode behavioral --skill rocprof-compute-memory` - Put a stub `claude` that exits 1 on `PATH` and run routing mode ## Test Result Works locally on gfx950: routing runs to completion with a summary, behavioral runs show no permission denials, and the stub CLI fails every case. ## Submission Checklist - [ ] 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>

…12190) ## Motivation Rocprofiler-compute had incorrect data and was hard to use. Therefore, while doing an analysis in the roofline, I've fixed some of these issues. ## Technical Details Changes are: - Kernel names are limited in size to 200 symbols. One of the side effects of the long kernel name was that for extremely long kernel names, their preview in tooltip glithched. - Tooltip which shows a full kernel name is added when you hover on a kernel in the kernel list on the right. - Tooltip for kernel on the plot is changed to structure the data better, so it's easier to inspect it. - New "AI axis" mode is added which shows a kernel point which is a bottleneck (ex. if L1 is a bottleneck, the L1 point is shown. If kernel is compute bound then the left-most point is shown). This mode is made default. - Default state of HTML is updated to always show FP32, FP16, FP8 rooflines when HTML is opened. - Roofline benchmark is updated: - FP16 and BF16 MFMA intrinsics updated. - Max is taken for roofline value instead of average. ## Issue Tracking AIPROFCOMP-853 ## Test Plan Manual validation for various pytorch bmm operators. Unit tests. ## Test Result Kernels show a proper limiter now, metrics in tooltip make sense, unit tests pass. ## Submission Checklist - [x ] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. [AIPROFCOMP-232]: https://amd-hub.atlassian.net/browse/AIPROFCOMP-232?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com> Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Carrie Fallows <Carrie.Fallows@amd.com>

## 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>

…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>

…sts, and docs (#12553)

## Motivation Roofline CLI plot does not offer the features necessary to support useful roofline analysis; users instead should use the HTML roofline output. Roofline 4.3 block is removed, leaving users the table outputs for roofline analysis in block 4, and the aforementioned roofline HTML plot output file. ## Technical Details - Changelog entry - Removed cli_generate_plot() and all related usage of cli plot generation and display requests - Removed all unit and integration tests (or parts of tests) checking for 4.3 roofline plot - Block 4 prints the path of the saved roofline HTML under its heading; removed the old log message without the path - Removed code only the CLI plot used: plotext requirement, CLI trace colors, get_color backend argument, Roofline.get_dtype - Docs: replaced the CLI roofline screenshot with block 4 text output, refreshed the interactive HTML screenshot, removed terminal plot notes ## Issue Tracking AIPROFCOMP-654 ## Test Plan Manual profiling and analysis on MI350X: - `analyze` - `analyze -b 4` - `analyze -b 2 4 5` - check html output is fine - ctest fine Profile with `--roof-only` on `tests/rocflop`, then: - `analyze` - `analyze -b 4` - `analyze -b 4 --view table` - unit tests ## Test Result All above manual tests and ctest fine. Works locally on MI350; the HTML path is printed in both views. ## Submission Checklist - [X] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. --------- Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com> Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…#14029) ## Motivation With the CLI roofline plot removed, `analyze --sort`, `--mem-level`, and `--roofline-data-type` no longer change the CLI output. The roofline HTML shows every memory level and precision, and both can be filtered in the browser. This removes the three options. ## Technical Details - Remove the options from the analyze parser; the roofline always uses every memory level the GPU benchmarks - Roofline skill reads the precision and memory level from the roofline tables or the analysis database - Update docs, changelog, and tests to match ## Issue Tracking AIPROFCOMP-654 ## Test Plan - `analyze` and `analyze -b 4` on profiled workloads - Check the roofline HTML lists every precision and memory level - Check `-R`, `-m`, and `--sort` are rejected - Unit tests ## Test Result Works locally on MI350. ## 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) --------- Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Co-authored-by: Carrie Fallows <Carrie.Fallows@amd.com>

## Motivation Profile mode collects only the counters that metric equations use. Bugfix: counters named only in comments, descriptions, metric names or `coll_level` are no longer profiled (131 counters that no metric reads). ## Technical Details - `utils_counter_defs.metric_value_keys()` and `metric_expressions()` are the one rule for which metric fields are table values and expressions. The parser, `detect_counters()` (every filter form), metric-aware coalescing, the sets single-pass check and the counter grouping inspector use it. - Dropped: the 2 level counters named by `coll_level` on each CDNA arch and gfx1250 (the formulas read their `_ACCUM` counters), 6 more on gfx115x, 16 more on gfx1250, and 95 more on gfx950 with `--membw-analysis`. None added. - Removed the `coll_level` key from the panel configs and the `alias` handling from the parser. Nothing reads either. - A unit test checks that the panels (`-b <panel>`) add up to the default and `--membw-analysis` profiles on every arch. - A malformed panel YAML now stops profiling, as it already did with `-b` and in analyze. ## Issue Tracking JIRA ID: AIPROFCOMP-959 ## Test Plan - In the ROCm container: `pytest tests/unit` and `tools/validate_sets_metric_ids.py`. - Refactors: old vs new parser tables and config iterator output on every arch. - Old vs new `detect_counters()` on 8 archs in 187 filter cases (no filter, `--membw-analysis`, every `-b` panel, every `--set`). - gfx950: one `--membw-analysis` profile analyzed with and without the dropped counters' data in 27 analyze cases (normalization units, filters, lists, display options, csv/txt/db output, workload comparison). - gfx950: profile and analyze with this PR, and count the profiling passes with and without it. ## Test Result - Unit tests and pre-commit checks pass. - The parser builds identical tables and the iterator yields identical metrics. - No counter is added in any filter case; 131 are dropped. - Analyze output is identical in all 27 cases. - gfx950 profiles in 21 passes instead of 29 with `--membw-analysis`, and in 20 passes without it, as before. - Not run on gfx1250, gfx115x or older CDNA GPUs, with the native counter tool, or with `--iteration-multiplexing`. ## 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>

- Generate the ground-truth runner and workload scripts in pytest's tmp_path, outside the directory that coverage measures. - Fixes generate_coverage_report failing with "No source for code" when tests run from the install directory. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

- Run test-torch-trace-collector through a shell that adds its library folders, stored relative to ROCM_PATH, to LD_LIBRARY_PATH. Build and install mode both use it, so installed tests find torch without the caller exporting torch/lib and host-math/lib. - Use coverage paths relative to the test directory, so a moved install writes its own coverage report. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…d typos Replace wrong GL2C_WRITE and LDS_PARAM_LOAD text, fix SARB/TCP/instruction typos, and make read versus write GCEA and related descriptions specific. Co-authored-by: Cursor <cursoragent@cursor.com>

Spell out the CPC interface units and describe GCEA size counters as totals in 32-byte units. Co-authored-by: Cursor <cursoragent@cursor.com>

…ding Use the same Number-of sentence for texture-cache instruction requests, LDS parameter loads, GL2 writes, and transcendental VALU sums. Co-authored-by: Cursor <cursoragent@cursor.com>

Co-authored-by: Venkateshwar Reddy Kandula <Venkateshwarreddy.Kandula@amd.com>

…r_def_in_rocprof_description

github-actions · 2026-10-27T18:16:15Z

Code Coverage Report

Tests Only

Samples Only

Tests + Samples

therock-pr-bot · 2026-10-27T19:16:54Z

✅ All Policy Checks Passed

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	PR does not contain code files — Unit Test auto-passed
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—

🎉 All policy checks passed!

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

…cription

…ters added to sdk yaml (#13817)

systems-assistant · 2026-10-29T04:43:25Z

TheRock Submodule Bump Activity

Newest first

2026-10-29 — Included in TheRock via ROCm/TheRock#9567.

vedithal-amd and others added 30 commits September 28, 2026 20:00

[rocprofiler-compute] Add ROCm 10.3 changelog section, bump to 3.11.0

338c9ff

- Add `ROCm Compute Profiler 3.11.0 for ROCm 10.3.0` changelog section using the empty subsection template - Bump VERSION 3.10.0 -> 3.11.0 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Merge branch 'develop' into rocprofiler-compute-develop

1ab55f0

Merge branch 'develop' into rocprofiler-compute-develop

469be29

- argparser.py: keep the --gui/--tui removal and develop's _skills_note() - .config_hashes.json: regenerated with hash_manager.py from the merged YAMLs Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Merge branch 'develop' into rocprofiler-compute-develop

e3354b6

Merge branch 'develop' into rocprofiler-compute-develop

c8ee5dd

Merge branch 'develop' into rocprofiler-compute-develop

d684a5b

Merge branch 'develop' into rocprofiler-compute-develop

87866a5

Merge branch 'develop' into rocprofiler-compute-develop

8693346

Merge branch 'develop' into rocprofiler-compute-develop

f8fac55

Merge branch 'develop' into rocprofiler-compute-develop

20c2d43

Merge branch 'develop' into rocprofiler-compute-develop

43e5943

fix(rocprofiler-compute): correct counter name (#13649)

ce767e6

refactor(rocprofiler-compute): Remove dead code across src, tools, te…

b02f26d

…sts, and docs (#12553)

cfallows-amd and others added 5 commits October 26, 2026 22:37

vedithal-amd force-pushed the rocprofiler-compute-develop branch from e5a377e to 6e750ee Compare October 26, 2026 22:38

feizheng10 and others added 3 commits October 27, 2026 09:16

fix(rocprofiler-sdk): correct gfx11 counter description copy-paste an…

9a3c7a6

…d typos Replace wrong GL2C_WRITE and LDS_PARAM_LOAD text, fix SARB/TCP/instruction typos, and make read versus write GCEA and related descriptions specific. Co-authored-by: Cursor <cursoragent@cursor.com>

fix(rocprofiler-sdk): expand GCRIU, RCIU, and DRAM size descriptions

bb49633

Spell out the CPC interface units and describe GCEA size counters as totals in 32-byte units. Co-authored-by: Cursor <cursoragent@cursor.com>

fix(rocprofiler-sdk): align counter descriptions with neighboring wor…

3875469

…ding Use the same Number-of sentence for texture-cache instruction requests, LDS parameter loads, GL2 writes, and transcendental VALU sums. Co-authored-by: Cursor <cursoragent@cursor.com>

github-actions Bot added documentation Improvements or additions to documentation project: rocprofiler-compute labels Oct 27, 2026

ywang103-amd and others added 3 commits October 27, 2026 09:37

Update projects/rocprofiler-sdk/source/share/rocprofiler-sdk/config.yaml

64a1d39

Co-authored-by: Venkateshwar Reddy Kandula <Venkateshwarreddy.Kandula@amd.com>

Update projects/rocprofiler-sdk/source/share/rocprofiler-sdk/config.yaml

b922192

Co-authored-by: Venkateshwar Reddy Kandula <Venkateshwarreddy.Kandula@amd.com>

Merge branch 'rocprofiler-compute-develop' into users/ywang103/counte…

b0084ae

…r_def_in_rocprof_description

ywang103-amd requested a review from venkat1361 October 27, 2026 14:18

precommit format

e33a32b

venkat1361 requested changes Oct 27, 2026

View reviewed changes

Comment thread projects/rocprofiler-sdk/source/share/rocprofiler-sdk/config.yaml Resolved

fix "SQC_TC_INST_REQ"'s description in "metrics_test.h"

984f1dc

ywang103-amd requested a review from venkat1361 October 27, 2026 16:55

venkat1361 approved these changes Oct 27, 2026

View reviewed changes

Base automatically changed from rocprofiler-compute-develop to develop October 27, 2026 19:15

ywang103-amd added 3 commits October 27, 2026 15:50

Merge branch 'develop' into users/ywang103/counter_def_in_rocprof_des…

663f366

…cription

Merge branch 'develop' into users/ywang103/counter_def_in_rocprof_des…

e17bef9

…cription

Merge branch 'develop' into users/ywang103/counter_def_in_rocprof_des…

8733d4a

…cription

ywang103-amd merged commit 518cddf into develop Oct 28, 2026
122 of 126 checks passed

ywang103-amd deleted the users/ywang103/counter_def_in_rocprof_description branch October 28, 2026 14:00

ywang103-amd added a commit that referenced this pull request Oct 28, 2026

feat(rcoprofiler-compuite): add missing descriptions of previous coun…

feb298a

…ters added to sdk yaml (#13817)

Navigation Menu

Repository navigation

feat(rcoprofiler-compuite): add missing descriptions of previous counters added to sdk yaml - #13817

feat(rcoprofiler-compuite): add missing descriptions of previous counters added to sdk yaml#13817
ywang103-amd merged 137 commits into
developfrom
users/ywang103/counter_def_in_rocprof_description

ywang103-amd commented Oct 20, 2026

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 •

edited

Loading

Code Coverage Report

Code Coverage Report

Tests Only

Samples Only

Tests + Samples

Uh oh!

therock-pr-bot Bot commented Oct 27, 2026 •

edited

Loading

Uh oh!

Uh oh!

systems-assistant Bot commented Oct 29, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

Conversation

ywang103-amd commented Oct 20, 2026

Motivation

Technical Details

Issue Tracking

Test Plan

Test Result

Submission Checklist

Uh oh!

Uh oh!

github-actions Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage Report

Code Coverage Report

Tests Only

Samples Only

Tests + Samples

Uh oh!

therock-pr-bot Bot commented Oct 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ All Policy Checks Passed

Uh oh!

Uh oh!

systems-assistant Bot commented Oct 29, 2026

TheRock Submodule Bump Activity

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

github-actions Bot commented Oct 27, 2026 •

edited

Loading

therock-pr-bot Bot commented Oct 27, 2026 •

edited

Loading