Repository navigation
sprint(rocprofiler-compute): Q4 Sprint 1 - #12400
Open
vedithal-amd wants to merge 44 commits into
Open
vedithal-amd wants to merge 44 commits into
vedithal-amd wants to merge 44 commits into
Conversation
- 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>
vedithal-amd
added
documentation
❌ PR Check — Action Required
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
…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>
## 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 <!-- Explain the purpose of this PR and the goals it aims to achieve. --> Prevent a crash when --list-stats is used with CSV or DB output. ## Technical Details <!-- Explain the changes along with any relevant GitHub links. --> - Reject this unsupported combination during option sanitization with a clear error. - Add regression tests and update help text and documentation. ## Issue Tracking <!-- Include a GitHub Issue and/or JIRA ID. Do not post any full JIRA links here. --> <!-- GitHub issue: #1234 --> <!-- JIRA ID: EXAMPLECOMPONENT-1234 --> JIRA ID: ROCM-29368 ## Test Plan <!-- Explain any relevant testing done to verify this PR. --> - 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 <!-- Briefly summarize test outcomes. --> - 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>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…13742) ## Motivation <!-- Explain the purpose of this PR and the goals it aims to achieve. --> Prevent JAX/PyTorch PC sampling finalization failures when GPU addresses are reused. ## Technical Details <!-- Explain the changes along with any relevant GitHub links. --> - Decode instructions using the code object ID and relative address. - Add a regression test for reused addresses. ## Issue Tracking <!-- Include a GitHub Issue and/or JIRA ID. Do not post any full JIRA links here. --> <!-- GitHub issue: #1234 --> <!-- JIRA ID: EXAMPLECOMPONENT-1234 --> JIRA ID: ROCM-32558 ## Test Plan <!-- Explain any relevant testing done to verify this PR. --> - Run collector tests. - Validate JAX sampling and PyTorch cold-cache training on MI350X. - Check clean exit, cleanup and ISA output. ## Test Result <!-- Briefly summarize test outcomes. --> - All 68 PC sampling collector tests passed, including the new test for this bug. - JAX and PyTorch validation passed. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.
## Motivation The stochastic block 21 table labels issue and stall totals `count_issued` and `count_stalled`, while the CSV and database use `issue_count` and `stall_count`. Matching the names lets users carry the same fields across terminal, CSV, and database output. ## Technical Details - The analyze table now displays `issue_count` and `stall_count`, matching the CSV and database fields. - Preserve count calculations, column order, host-trap output, and per-kernel ISA CSV headings. - Cover empty, stochastic, host-trap, and display schemas in unit tests; check that block 21 shows `issue_count` and `stall_count` in the CLI integration test. <img width="1715" height="469" alt="pc_sampling" src="https://github.com/user-attachments/assets/9e8dfd16-9dcf-45fb-91ac-ffe44edad236" /> ## JIRA ID JIRA ID: ROCM-32929 ## Test Plan - [x] ctest --test-dir build -R '^(test_pc_sampling_analysis|test_pc_sampling_analyze_cli)$' ## Test Result - [x] ctest --test-dir build -R '^(test_pc_sampling_analysis|test_pc_sampling_analyze_cli)$' passes ## 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>
## Motivation The memory chart HTML work needs a shared report frame. This refactor moves the existing roofline page onto that frame while keeping its model and controls. ## Technical Details - Move document assembly, asset loading, and script-safe JSON embedding into shared HTML report utilities. - Keep the roofline plot fragment and page assets while the shared shell supplies the document frame and theme setup. - Register shared-shell unit coverage alongside the existing roofline tests. ## JIRA ID JIRA ID: AIPROFCOMP-868 ## Test Plan - [x] Run ctest for the roofline main, roofline analyze, and HTML report targets. ## Test Result - [X] ctest for the roofline main, roofline analyze, and HTML report targets pass ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. [AIPROFCOMP-868]: https://amd-hub.atlassian.net/browse/AIPROFCOMP-868?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
## Motivation The memory chart HTML work in [AIPROFCOMP-868](https://amd-hub.atlassian.net/browse/AIPROFCOMP-868) needs report controls and panels that can be styled consistently. This refactor builds on #12529 and keeps the roofline page appearance. ## Technical Details - Move common report layout, panel, control, and theme styles into a shared base stylesheet. - Rename the generic roofline CSS classes and variables to report names while keeping roofline-only rules local. - Keep roofline element IDs and controls compatible with its existing JavaScript and tests. ## JIRA ID JIRA ID: AIPROFCOMP-868 ## Test Plan - [x] Run ctest for the roofline main, roofline analyze, and HTML report targets. - [x] Run workload: Open a generated two-kernel roofline page offline and verify theme, selection, Ctrl-click, Show all, and PNG export. ## Test Result - [x] ctest for the roofline main, roofline analyze, and HTML report targets pass ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. [AIPROFCOMP-868]: https://amd-hub.atlassian.net/browse/AIPROFCOMP-868?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
## Motivation The memory chart HTML work needs a kernel picker shared with roofline. This refactor builds on #12530 and keeps roofline selection behavior. ## Technical Details - Add a shared kernel list with single and multi selection modes, row decoration, state updates, and count text. - Route roofline kernel row and plot clicks through the shared selection state, including Ctrl-click from an empty selection. - Keep roofline-specific roof controls and off-plot badges in the roofline page. ## JIRA ID JIRA ID: AIPROFCOMP-868 ## Test Plan - [x] Run ctest for the roofline main, roofline analyze, and HTML report targets. - [x] Run workload: Open a generated two-kernel roofline page offline and verify theme, selection, Ctrl-click, Show all, and PNG export. ## Test Result - [x] ctest for the roofline main, roofline analyze, and HTML report targets pass. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. [AIPROFCOMP-868]: https://amd-hub.atlassian.net/browse/AIPROFCOMP-868?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…x908 and gfx90a (#13794)
#13825) ## Motivation <!-- Explain the purpose of this PR and the goals it aims to achieve. --> Bugfix: stochastic PC sampling stall reasons now count only samples where the wave did not issue, as the [ROCprofiler-SDK docs](https://rocm.docs.amd.com/projects/rocprofiler-sdk/en/latest/how-to/using-pc-sampling.html) define them. Each instruction's stall reasons add up to its `stall_count`, and issued samples no longer show up as `OTHER_WAIT`. ## Technical Details <!-- Explain the changes along with any relevant GitHub links. --> - Drop the stall reason of issued samples when loading PC samples. The terminal table, `pc_sampling_summary.csv`, the analysis database, and the per-kernel ISA CSV all read from there. - Give the issued sample in the existing unit test a stall reason, as real SDK data has. - Correct the two affected example rows in the PC sampling docs. ## Issue Tracking <!-- Include a GitHub Issue and/or JIRA ID. Do not post any full JIRA links here. --> <!-- GitHub issue: #1234 --> <!-- JIRA ID: EXAMPLECOMPONENT-1234 --> JIRA ID: ROCM-32866 ## Test Plan <!-- Explain any relevant testing done to verify this PR. --> - Run the PC sampling analysis and parser unit tests. - Run the updated unit test without the fix to confirm it fails. ## Test Result <!-- Briefly summarize test outcomes. --> - Unit tests pass locally, and the updated test fails without the fix. ## 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>
…l api tracing (#11798) ## Motivation ML API tracing emits one ROCTX range per call, with operator arguments and thread ids on the marker, instead of stacked marker paths. Marker `Function` text changes from stacked `nn.Module.Net.forward/nn.Module.Linear.forward:#1@train.py:27/#2@train.py:19` paths to one-level `nn.Module.Linear.forward:train.py:19|seqNr=n/a|tid=n/a|ftid=n/a|ltid=n/a|scope=n/a|args=n/a|torch`. Parsing the values and correlation is done in `analyze `phase. ## Technical Details - Marker: `encode(name):<location>|seqNr=<v>|tid=<v>|ftid=<v>|ltid=<v>|scope=<v>|args=<v>|<backend>`. `/` and `%` in the name are encoded. Backend is a raw trailing `|torch` or `|triton`. Python wraps use user `file:line` (or `n/a`) and leave seqNr/tid/ftid/ltid/scope as `n/a`. RecordFunction uses `n/a` as location and fills the other fields when available. - `src/lib/torch_trace_collector`: RecordFunction callback pushes that range. Args from inputs and schema names, capped and encoded. Library: `torch_trace_collector.so`. - Removed stacked collector: snapshot store, marker stack, leaf context, pybind, C++ collector tests. - `src/utils/inject_roctx/_backends/torch_trace_collector.py`: ctypes-load the `.so`, call `torch_trace_collector_install`. Push/pop launcher tid around selected autograd wraps. - `src/utils/inject_roctx`: torch and triton wraps use the same wire; each call pushes and pops its own range. A Triton `JITFunction.run` that calls `CompiledKernel.run` emits both markers. - `src/utils/utils_profile.py`: `save_ml_api_trace_inputs` copies marker and counter CSVs unchanged. - Removed tests: `test_torch_cpp_loader`, `test-torch-trace-collector`, `test_torch_trace_coverage`, `test_profile_triton_trace`, `test_triton_backend_reentrancy_dedups_nested_launch`. - This wire no longer matches the old stacked `:#` shape. Analyze does not work on this output; that is #11830. - Restore Torch-independent collector builds with a generic `torch_trace_collector.so`, using the application's PyTorch at runtime. - Fix missing tensor metadata and stale operator argument names, limit tensor-list traversal, and preserve the correct subclass binding for inherited `Function.apply`. - Regression tests for these fixes are in #12809, stacked on #11834. ## Issue Tracking JIRA ID: AIPROFCOMP-860 ## Test Plan `rocprof-compute profile --experimental -b 2.1.1 --torch-trace -n simpleCode -- python3 simple_net.py --dry-run --epochs 1 --batch-size 1` ## Test Result From marker_trace.csv, `Domain,Function,Process_Id,Thread_Id,Correlation_Id,GUID,Start_Timestamp,End_Timestamp MARKER_CORE_RANGE_API,nn.Module.SimpleNet.__init__:simple_net.py:30|seqNr=n/a|tid=n/a|ftid=n/a|ltid=n/a|scope=n/a|args=n/a|torch,6921,6921,1,000084b2-a044-7044-b2bd-c1a4d65f6110,2226300689148270,2226300689187709 MARKER_CORE_RANGE_API,nn.Module.Linear.__init__:simple_net.py:31|seqNr=n/a|tid=n/a|ftid=n/a|ltid=n/a|scope=n/a|args=n/a|torch,6921,6921,2,000084b2-a044-7044-b2bd-c1a4d65f6110,2226300690158420,2226300690174264 MARKER_CORE_RANGE_API,torch.empty:simple_net.py:31|seqNr=n/a|tid=n/a|ftid=n/a|ltid=n/a|scope=n/a|args=n/a|torch,6921,6921,3,000084b2-a044-7044-b2bd-c1a4d65f6110,2226300690210037,2226300690347283 MARKER_CORE_RANGE_API,"aten::empty:n/a|seqNr=n/a|tid=1|ftid=0|ltid=n/a|scope=FUNCTION|args=(size=GenericList, dtype=None, layout=None, device=Device, pin_memory=Bool, memory_format=None)|torch",6921,6921,4,000084b2-a044-7044-b2bd-c1a4d65f6110,2226300690316316,2226300690342836 MARKER_CORE_RANGE_API,aten::detach:n/a|seqNr=0|tid=1|ftid=0|ltid=n/a|scope=FUNCTION|args=(self=float32[20x10])|torch,6921,6921,5,000084b2-a044-7044-b2bd-c1a4d65f6110,2226300690389606,2226300690411058 ` ## Submission Checklist - [ ] Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md. --------- Co-authored-by: Harsha Bajpai <habajpai@amd.com> Co-authored-by: Vignesh Edithal <Vignesh.Edithal@amd.com> Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ator call tree (#11830) ## Motivation Analyze correlates ROCTX markers and GPU dispatches into an ML operator call tree and prints that tree for the torch and triton list and filter commands. Nesting is by thread and timestamps; unlocated torch/triton trees are then attached onto the autograd launcher thread. ## Technical Details - Load marker/counter pairs; collapse counters by `Dispatch_ID`; outer-join kernels to markers. - Match markers across passes on the `Function` text without `ltid`, plus its occurrence order in the pass. - Parse the roctx marker name `Function` wire (`name:location|seqNr=…|…|backend`). - Nest by thread and timestamps; attach unlocated torch/triton trees by autograd launcher thread (`ltid`). - Prune CPU-only paths, then roll up GPU time and dispatch counts. - `--list-*-operators` / `--*-operator` print that tree (fold identical siblings) plus a per-operator summary. - Backend filter re-rolls the kept view; listing assigns kernel ids on copies. - Pass mismatch, overlapping or unnested markers, and kernel list length mismatch stop analyze with an error. Unmatched kernels, failed attach, and missing source print warnings before the tree. - Analyze does not write `consolidated.csv`. - PYTHON_CODING_STYLE.md: forbid `if TYPE_CHECKING:` imports. ## Issue Tracking JIRA ID: AIPROFCOMP-860 ## Test Plan On --torch-trace profiling output, `rocprof-compute analyze --experimental --list-torch-operators -p workloads_path` `rocprof-compute analyze --experimental --torch-operator "*line*" -p workload_path` ## Test Result On `sample/simple_net.py` , [operator_listing.txt](https://github.com/user-attachments/files/32570443/operator_listing.txt) [operator_filtering.txt](https://github.com/user-attachments/files/32570445/operator_filtering.txt) On a simple torch code that launches threads to run `backward()` , [threaded_code.py](https://github.com/user-attachments/files/32570665/threaded_code.py) [threaded_operator_listing.txt](https://github.com/user-attachments/files/32570628/threaded_operator_listing.txt) [threaded_operator_filtering.txt](https://github.com/user-attachments/files/32570637/threaded_operator_filtering.txt) ## Submission Checklist - [ ] 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>
…ll trees (#11834) ## Motivation Tests and docs for ML API tracing (`--torch-trace`, `--triton-trace`, `--ml-api-trace`) ## Technical Details - Unit tests for `inject_roctx` (install, TritonBackend, TorchBackend, LazyLinear `.to`) - Unit tests for nest/join/filter/glob, analyze CLI, and profile sanitize of the ML flags - GPU CTests launch `./tests/simple_net.py`, `./tests/triton_ffn.py`, and `./tests/torch_triton_net.py` (CMake copies those from `sample/`), plus sampled `torch.ops` (for comparison with `torch.profiler`) - Docs: CLI operator analyze, collector one-level design, `--triton-trace` does not see Inductor static launches - Changelog: user-visible ML API tracing changes only - ML API trace analyze requires `GUID` in the marker and counter CSVs - CONTRIBUTING.md: Writing for Users guideline - Dropped checked-in golden ML workloads - CTest/marker/workload details in [ml_api_trace_test_framework.md](https://github.com/user-attachments/files/33590528/ml_api_trace_test_framework.md) ## Issue Tracking JIRA ID: AIPROFCOMP-860 ## Test Plan `ctest --output-on-failure -R '^(test_profile_torch_trace|test_profile_triton_trace|test_profile_ml_api_trace|test_torch_trace_coverage|test_inject_roctx_package|test_inject_roctx_torch|test_analysis_cli|test_utils_analysis|test_analyze_commands|test_profiler_base|test_analysis_base|test_parser)$'` ## Test Result All ctests pass. ## Submission Checklist - [ ] 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>
## Motivation <!-- Explain the purpose of this PR and the goals it aims to achieve. --> Add regression tests for the PyTorch tracing fixes in #11798. This PR is stacked on #11834. ## Technical Details <!-- Explain the changes along with any relevant GitHub links. --> - Test collector loading, schema caching, tensor metadata/limits, inherited `Function.apply`, and lazy tensors. - Strengthen GPU marker checks, fail when the native collector does not load, and reuse parse_marker_function for decoding. - Add native test targets, preserve installed-test library paths, and update test setup and docs. ## Issue Tracking <!-- Include a GitHub Issue and/or JIRA ID. Do not post any full JIRA links here. --> <!-- GitHub issue: #1234 --> <!-- JIRA ID: EXAMPLECOMPONENT-1234 --> JIRA ID: AIPROFCOMP-912 ## Test Plan <!-- Explain any relevant testing done to verify this PR. --> - Build with Torch and tests enabled. - Run native collector tests and Python unit/analysis tests. - Run Torch integration tests with the native collector, plus the ROCTX user-range test. ## Test Result <!-- Briefly summarize test outcomes. --> Validated after rebasing onto #11834, on MI350X with ROCm `10.2.0a20261019` and Torch `2.14.0+rocm10.2.0a20261019`. - Full build passed. - 19 native C++ cases and 193 Python unit/analysis cases passed. - ROCTX user-range test passed. - Five integration tests passed in native mode and five in forced ABI-failure fallback mode. Both modes were verified. - Zero skips, failures or errors. ## 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>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
## 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>
This branch has not been deployed
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.
Important
Merge via rebase-and-merge, NOT squash-and-merge.
Motivation
Q4 Sprint 1 for rocprofiler-compute, targeted for ROCm 10.3
Sprint PR merge deadline: Oct 26
Each commit here corresponds to a rocprofiler-compute PR
The entire sprint work will be contributed to develop branch as a single PR via rebase and merge (NOT squash and merge) to preserve authorship and audit trail
Technical Details
Issue Tracking
JIRA ID: N/A
Test Plan
Test Result
Submission Checklist