* External CI: rename pipeline to rocprofiler-compute (#463)
Signed-off-by: Daniel Su <danielsu@amd.com>
* Update webui branding (#459)
* Update name and icon for browser tab to rocprofiler-compute.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Update name and icon for browser tab to rocprofiler-compute.
Signed-off-by: xuchen-amd <xuchen@amd.com>
---------
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Update branding in documentation (#442)
* find/replace Omniperf to ROCm Compute Profiler
Signed-off-by: Peter Park <peter.park@amd.com>
* update name in Sphinx conf
Signed-off-by: Peter Park <peter.park@amd.com>
* mv what-is-omniperf.rst -> what-is-rocprof-compute.rst
Signed-off-by: Peter Park <peter.park@amd.com>
* update Tutorials section
Signed-off-by: Peter Park <peter.park@amd.com>
* add Omniperf as keyword to Conceptual section for internal search
Signed-off-by: Peter Park <peter.park@amd.com>
* update Reference section
Signed-off-by: Peter Park <peter.park@amd.com>
* black fmt conf.py
Signed-off-by: Peter Park <peter.park@amd.com>
* update profile mode and basic usage subsections
Signed-off-by: Peter Park <peter.park@amd.com>
* update how to use analyze mode subsection
Signed-off-by: Peter Park <peter.park@amd.com>
* update install section
Signed-off-by: Peter Park <peter.park@amd.com>
* fix sphinx warnings
Signed-off-by: Peter Park <peter.park@amd.com>
* fix cmd line examples in profile/mode.rst
Signed-off-by: Peter Park <peter.park@amd.com>
* update install decision tree image
Signed-off-by: Peter Park <peter.park@amd.com>
* fix TOC and index
Signed-off-by: Peter Park <peter.park@amd.com>
fix weird wording
* fix cli text: deriving rocprofiler-compute metrics...
Signed-off-by: Peter Park <peter.park@amd.com>
* update standalone-gui.rst
Signed-off-by: Peter Park <peter.park@amd.com>
* restore removed doc updates from #428
Signed-off-by: Peter Park <peter.park@amd.com>
* update ref to Omniperf in index.rst
Signed-off-by: Peter Park <peter.park@amd.com>
* fix grafana connection name to match image
Signed-off-by: Peter Park <peter.park@amd.com>
* update cmds in tutorials
Signed-off-by: Peter Park <peter.park@amd.com>
---------
Signed-off-by: Peter Park <peter.park@amd.com>
* MI300 roofline enablement in rocprofiler-compute (#470)
* MI300 roofline enablement in rocprofiler-compute
requirements.txt
- running some modules complained about numpy version too new, adding extra requirement that numpy be 1.x
pmc_roof_perf.txt
- adding TCC_BUBBLE_sum counter to profile
soc_gfx940.py
soc_gfx941.py
soc_gfx942.py
- remove console logs reading that roofline is temporarily disabled, uncommenting blocks that check for roofline csv and run roofline post-processing
roofline_calc.py
- add mi300 to supported soc
- add new calculation for hbm_data for MI300 using tcc_bubble_sum, checks if counter > 0 to use
- add to a few comments
roofline-ubuntu-20_04-mi300-rocm6
- binary for the ubuntu systems to enable mi300 roofline calculations from rocm-amdgpu-bench
Note- other distros will get roofline bins to enable mi300, but need to be further tested before putting into branch.
Signed-off-by: Carrie Fallows <carrie.fallows@amd.com>
* Reformatting roofline_calc.py
Signed-off-by: Carrie Fallows <carrie.fallows@amd.com>
---------
Signed-off-by: Carrie Fallows <carrie.fallows@amd.com>
* Update Python format checker (#471)
* Add pre commit hook for Python formatting
Signed-off-by: coleramos425 <colramos@amd.com>
* Update formatting workflow to run on latest Python and add isort formatter
Signed-off-by: coleramos425 <colramos@amd.com>
* Fix caught yaml formatting issues
* Update pyproject file
* Add pre-commit hook instruction to CONTRIBUTING guide
* Remove target-version from black pyproject.toml
* Fixed formatting errors found with black and isort
Signed-off-by: David Galiffi <David.Galiffi@amd.com>
* Run hook: Whitespaces, fix end of file spaces
---------
Signed-off-by: coleramos425 <colramos@amd.com>
Signed-off-by: David Galiffi <David.Galiffi@amd.com>
Co-authored-by: David Galiffi <David.Galiffi@amd.com>
* Bump cryptography from 43.0.0 to 43.0.1 in /docs/sphinx (#473)
Bumps [cryptography](https://github.com/pyca/cryptography) from 43.0.0 to 43.0.1.
- [Changelog](https://github.com/pyca/cryptography/blob/main/CHANGELOG.rst)
- [Commits](https://github.com/pyca/cryptography/compare/43.0.0...43.0.1)
---
updated-dependencies:
- dependency-name: cryptography
dependency-type: indirect
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Fix file permission on MI300 roofline binary (#477)
Signed-off-by: David Galiffi <David.Galiffi@amd.com>
* Removing numpy requirements of <2 (#478)
Checks are failing if version too high and no need for lower version
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Fix crash when loading web UI roofline for gfx942 (#479)
* Fix crash when loading web UI roofline for gfx942
* Fix formatting
Signed-off-by: benrichard-amd <ben.richard@amd.com>
* Make same changs for gfx940, gfx942.
Signed-off-by: benrichard-amd <ben.richard@amd.com>
* Fix formatting in soc_gfx940 and soc_gfx941.
Signed-off-by: benrichard-amd <ben.richard@amd.com>
---------
Signed-off-by: benrichard-amd <ben.richard@amd.com>
* Rebranding name change patch (#469)
* Patch in missed name change for rebranding.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Patch in missed name change for rebranding.
Signed-off-by: xuchen-amd <xuchen@amd.com>
---------
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Move dependabot.yml to .github/ and bump rocm-docs-core (#481)
* Move dependabot.yml to .github/
* Bump rocm-docs-core to 1.8.5
* Bump rocm-docs-core to 1.9.0
* Fix packaging for upgrading (#486)
Specify that "rocprofiler-compute" replaces / obsoletes the "omniperf" package.
* Renamed extension path from omniperf to rocprofiler_compute (#487)
Signed-off-by: Tim Gu <Tim.Gu@amd.com>
* MI300 rhel and sles roofline binaries (#480)
* Roofline bins for MI300 on rhel and sles distributions
Built from rocm-amdgpu-bench, tested on respective distro systems with MI300 hardware.
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Minor modifications removing hardcoded variables in roofline files.
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
---------
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Modify test_profile_general.py ctest to include MI300 enablement (#498)
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* part 1 to support rocprofv3 (#492)
* rocprofv3 support initial commit
-Can run rocprofv3 but ultimately fails. rocprofv3 says the counter capacity
is exceeded and the output CSV file format is different from v1/v2.
* Add rocprofv3 detection so v2 can still be used
It's hacky but it'll do for now.
* Add code path to convert rocprofv3 JSON output into CSV
* Grab correct value for Queue ID
* Use _sum suffix to sum TCC counters
Previously we were specifying each channel for TCC counters. rocprofv3 does
not support specifing each TCC channel, and instead will auto sum given
the TCC counter name. The counter name with the _sum suffix is also
supported and is also supported in v1 and v2. So we will use the TCC
counter name with the _sum suffix.
* Fix incorrect counter outputs when using rocprofv3
In the JSON output some counters appear multime times and must be
summed to get the correct value. These summed values match the
rocprofv3 output in CSV mode and also match the rocprofv2
output.
* Remove duplicate Correlation_ID and Wave_Size in output
* Handle json output that does not contain any dispatches
Omniperf was assuming each JSON output from rocprofv3 would always contain
dispatches. This is not the case. For example, in a multi-process
workload where one of the processes does not dispatch any kernels. A JSON
file will still be output for this process but it will not contain any dispatches.
* Code cleanup
* Update search path for rocprofv3 results
Rocprofv3 was updated to include the hostname in the path where
it outputs results.
* Handle accumulate counters
In v1/v2 rocprof uses the SQ_ACCUM_PREV_HIRES counter for the accumualte
counters. v3 does not have this. So we need to define our own counters
in counter_defs.yaml. For this we use the counter name + _ACCUM, for
example SQ_INSTR_LEVEL_SMEM_ACCUM.
To use rocprofv3 you will need to update counter_defs.yaml to include
these new counter definitions.
* Use correct GPU ID
When converting JSON -> CSV we were assigning node_id to GPU_ID. Since
the JSON contains non-GPU devices, the node_id for GPUs might not
start at 0 as expected.
This commit maps the agent ID to the appropriate GPU ID.
* Parse scratch memory per work item from JSON
* Support rocprofv3 CSV parsing
JSON decoding is very slow for large files. Include support for parsing
rocprofv3 CSV output and make that the default.
CSV/JSON can be toggled via the ROCPROF_OUTPUT_FORMAT environment
variable e.g. ROCPROF_OUTPUT_FORMAT=csv or ROCPROF_OUTPUT_FORMAT=json
* black format after merge
* format isort
* change return of rocprof_cmd to try to resolve test's error
* hack to pick last part of rocminfo's name
* debug log of hacks
* Modify test_profile_general.py ctest to include MI300 enablement. Currently failing because of explicitly excluded roofline files for the soc and autofailed asserts for roof-only tests- originally in place because roofline was not enabled on mi300 yet.
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* black and isort formated
* corrected line of copyright
---------
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
Co-authored-by: benrichard-amd <ben.richard@amd.com>
Co-authored-by: YANG WANG <ywang@ywang-ubuntu.amd.com>
Co-authored-by: Carrie Fallows <Carrie.Fallows@amd.com>
* fix for crash of timestamp of part 1 for rocprofv3 (#499)
* fix the error caused by ignoring the lack of counter csv file from rocprofv3 for timestamp
* isort and black formated
* quick fix for gfx906 roofline (#505)
* Multi node support (#503)
* [CTest] Pipeline failures for MI300 (#483)
* Propagate new chip_id logic to testing workflow
Signed-off-by: coleramos425 <colramos@amd.com>
* Add a debug line to tests
Signed-off-by: coleramos425 <colramos@amd.com>
* Trying to set rocprofv2 generally in CTest module
Signed-off-by: coleramos425 <colramos@amd.com>
* Remove temp debugging lines from CI
Signed-off-by: coleramos425 <colramos@amd.com>
* Add roofline entry for MI300 expected files in CI tests
Signed-off-by: coleramos425 <colramos@amd.com>
* Make num_devices modifier global in scope
Signed-off-by: coleramos425 <colramos@amd.com>
* Change kernel name in PyTest to confirm rocprofv2 bug
Related to https://ontrack-internal.amd.com/browse/SWDEV-503453
Signed-off-by: coleramos425 <colramos@amd.com>
---------
Signed-off-by: coleramos425 <colramos@amd.com>
* Spatial-multiplexing: part 1 profiling stage (#465)
* rocprofv3 support initial commit
-Can run rocprofv3 but ultimately fails. rocprofv3 says the counter capacity
is exceeded and the output CSV file format is different from v1/v2.
* Add rocprofv3 detection so v2 can still be used
It's hacky but it'll do for now.
* Add code path to convert rocprofv3 JSON output into CSV
* Grab correct value for Queue ID
* Use _sum suffix to sum TCC counters
Previously we were specifying each channel for TCC counters. rocprofv3 does
not support specifing each TCC channel, and instead will auto sum given
the TCC counter name. The counter name with the _sum suffix is also
supported and is also supported in v1 and v2. So we will use the TCC
counter name with the _sum suffix.
* Fix incorrect counter outputs when using rocprofv3
In the JSON output some counters appear multime times and must be
summed to get the correct value. These summed values match the
rocprofv3 output in CSV mode and also match the rocprofv2
output.
* Remove duplicate Correlation_ID and Wave_Size in output
* Handle json output that does not contain any dispatches
Omniperf was assuming each JSON output from rocprofv3 would always contain
dispatches. This is not the case. For example, in a multi-process
workload where one of the processes does not dispatch any kernels. A JSON
file will still be output for this process but it will not contain any dispatches.
* Code cleanup
* Update search path for rocprofv3 results
Rocprofv3 was updated to include the hostname in the path where
it outputs results.
* Handle accumulate counters
In v1/v2 rocprof uses the SQ_ACCUM_PREV_HIRES counter for the accumualte
counters. v3 does not have this. So we need to define our own counters
in counter_defs.yaml. For this we use the counter name + _ACCUM, for
example SQ_INSTR_LEVEL_SMEM_ACCUM.
To use rocprofv3 you will need to update counter_defs.yaml to include
these new counter definitions.
* debug code
* add logic code for multiplexing
* minor fix
* more fixes
* rocprofv3 support initial commit
-Can run rocprofv3 but ultimately fails. rocprofv3 says the counter capacity
is exceeded and the output CSV file format is different from v1/v2.
* Add rocprofv3 detection so v2 can still be used
It's hacky but it'll do for now.
* Add code path to convert rocprofv3 JSON output into CSV
* Grab correct value for Queue ID
* Use _sum suffix to sum TCC counters
Previously we were specifying each channel for TCC counters. rocprofv3 does
not support specifing each TCC channel, and instead will auto sum given
the TCC counter name. The counter name with the _sum suffix is also
supported and is also supported in v1 and v2. So we will use the TCC
counter name with the _sum suffix.
* Fix incorrect counter outputs when using rocprofv3
In the JSON output some counters appear multime times and must be
summed to get the correct value. These summed values match the
rocprofv3 output in CSV mode and also match the rocprofv2
output.
* Remove duplicate Correlation_ID and Wave_Size in output
* Handle json output that does not contain any dispatches
Omniperf was assuming each JSON output from rocprofv3 would always contain
dispatches. This is not the case. For example, in a multi-process
workload where one of the processes does not dispatch any kernels. A JSON
file will still be output for this process but it will not contain any dispatches.
* Code cleanup
* Update search path for rocprofv3 results
Rocprofv3 was updated to include the hostname in the path where
it outputs results.
* Handle accumulate counters
In v1/v2 rocprof uses the SQ_ACCUM_PREV_HIRES counter for the accumualte
counters. v3 does not have this. So we need to define our own counters
in counter_defs.yaml. For this we use the counter name + _ACCUM, for
example SQ_INSTR_LEVEL_SMEM_ACCUM.
To use rocprofv3 you will need to update counter_defs.yaml to include
these new counter definitions.
* count accu files as well
* Use correct GPU ID
When converting JSON -> CSV we were assigning node_id to GPU_ID. Since
the JSON contains non-GPU devices, the node_id for GPUs might not
start at 0 as expected.
This commit maps the agent ID to the appropriate GPU ID.
* fix error with csv file parse from json and merge during post-processing
* implemented parsing of csv files from v3 output for optimization
* Parse scratch memory per work item from JSON
* Support rocprofv3 CSV parsing
JSON decoding is very slow for large files. Include support for parsing
rocprofv3 CSV output and make that the default.
CSV/JSON can be toggled via the ROCPROF_OUTPUT_FORMAT environment
variable e.g. ROCPROF_OUTPUT_FORMAT=csv or ROCPROF_OUTPUT_FORMAT=json
* black format after merge
* format isort
* change return of rocprof_cmd to try to resolve test's error
* hack to pick last part of rocminfo's name
* debug log of hacks
* Modify test_profile_general.py ctest to include MI300 enablement. Currently failing because of explicitly excluded roofline files for the soc and autofailed asserts for roof-only tests- originally in place because roofline was not enabled on mi300 yet.
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* black and isort formated
* formated by isort and black
* change default rocprof's output to csv
* repaired crash caused by missing csv counter file when running for timestamp
* change name to spatial-multiplexing from multiplexing
* make necessary modification for review
* set the value of spatial_multiplexing in argument defautly to None
* repair the part that blocks regular pmc files' generation
---------
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
Co-authored-by: benrichard-amd <ben.richard@amd.com>
Co-authored-by: fei.zheng <fei.zheng@amd.com>
Co-authored-by: YANG WANG <ywang@ywang-ubuntu.amd.com>
Co-authored-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Simple fix for gpu model value. (#508)
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Add FP64 to plot adhering to pdf name (#507)
* Replacing FP32-only plot with an FP32&FP64 combo plot. Results will likely be negligible but the plot name indicates both should be graphed.
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Remove duplicate AI plot to clean up fp32 fp64 graph
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
---------
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Add gpu series for roofline (#510)
* Add gpu_series for roofline.
* Use gpu_series in path names for roofline.
* Fix TCC on MI200 when introduce rocprofv3 (#509)
* quick fix for v2
* one more fix
* revert a bit
---------
Co-authored-by: ywang103-amd <ywang103@amd.com>
* Bump rocm-docs-core from 1.9.0 to 1.12.0 in /docs/sphinx (#511)
Bumps [rocm-docs-core](https://github.com/ROCm/rocm-docs-core) from 1.9.0 to 1.12.0.
- [Release notes](https://github.com/ROCm/rocm-docs-core/releases)
- [Changelog](https://github.com/ROCm/rocm-docs-core/blob/develop/CHANGELOG.md)
- [Commits](https://github.com/ROCm/rocm-docs-core/compare/v1.9.0...v1.12.0)
---
updated-dependencies:
- dependency-name: rocm-docs-core
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Update sample roofline plot img (#516)
* Modify path to use gpu_model instead of gpu_series to match other workload directory path creation/search points. Affects manual testing, does not seem to affect ctests. (#513)
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
* Improve formatting when displaying rocprof command. (#476)
* Improve formatting when displaying rocprof command.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Fix python formatting.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Strip unwanted characters (rocprofv1 specific) from rocprof commands.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Strip unwanted characters (rocprofv1 specific) from rocprof commands.
Signed-off-by: xuchen-amd <xuchen@amd.com>
* Save the unmodified arguments for rocprof for debug message display.
Signed-off-by: xuchen-amd <xuchen@amd.com>
---------
Signed-off-by: xuchen-amd <xuchen@amd.com>
* quick fix for mpi_support (#518)
* Pass accumulate counters to rocprofv3 using -E option (#522)
rocprofv3 has a new -E option where extra counters can be passed (see accum_counters.yaml) instead
of defining them in counter_defs.yaml.
* Unify all file handling with pathlib (#512)
* Replace occurences of os.path functions with equivalent functions from
pathlib library
* Remove unwanted imports of os.path and os
* Add coding guidelines for using pathlib instead of os.path
* Auto sync staging and mainline on a weekly cadence (#517)
Signed-off-by: coleramos425 <colramos@amd.com>
---------
Signed-off-by: Daniel Su <danielsu@amd.com>
Signed-off-by: xuchen-amd <xuchen@amd.com>
Signed-off-by: Peter Park <peter.park@amd.com>
Signed-off-by: Carrie Fallows <carrie.fallows@amd.com>
Signed-off-by: coleramos425 <colramos@amd.com>
Signed-off-by: David Galiffi <David.Galiffi@amd.com>
Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Carrie Fallows <Carrie.Fallows@amd.com>
Signed-off-by: benrichard-amd <ben.richard@amd.com>
Signed-off-by: Tim Gu <Tim.Gu@amd.com>
Co-authored-by: Daniel Su <danielsu@amd.com>
Co-authored-by: xuchen-amd <xuchen@amd.com>
Co-authored-by: Peter Park <peter.park@amd.com>
Co-authored-by: cfallows-amd <Carrie.Fallows@amd.com>
Co-authored-by: David Galiffi <David.Galiffi@amd.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ben Richard <143630488+benrichard-amd@users.noreply.github.com>
Co-authored-by: Tim Gu <Tim.Gu@amd.com>
Co-authored-by: ywang103-amd <ywang103@amd.com>
Co-authored-by: benrichard-amd <ben.richard@amd.com>
Co-authored-by: YANG WANG <ywang@ywang-ubuntu.amd.com>
Co-authored-by: Fei Zheng <44449748+feizheng10@users.noreply.github.com>
Co-authored-by: fei.zheng <fei.zheng@amd.com>
Co-authored-by: vedithal-amd <Vignesh.Edithal@amd.com>
[ROCm/rocprofiler-compute commit: 272e5b6e32]
69 KiB
Analyze Mode
.. toctree::
:glob:
:maxdepth: 4
Omniperf offers several ways to interact with the metrics it generates from profiling. The option you choose will likely be influenced by your familiarity with the profiled application, computing environment, and experience with Omniperf.
While analyzing with the CLI offers quick and straightforward access to Omniperf metrics from terminal, the GUI adds an extra layer of styling and interactiveness some users may prefer.
See sections below for more information on each.
Profiling results from the [aforementioned vcopy workload](profiling.md#workload-compilation) will be used in the following sections to demonstrate the use of Omniperf in MI GPU performance analysis. Unless otherwise noted, the performance analysis is done on the MI200 platform.
CLI Analysis
Features
- Derived metrics: All of Omniperf's built-in metrics.
- Baseline comparison: Compare multiple runs in a side-by-side manner.
- Metric customization: Isolate a subset of built-in metrics or build your own profiling configuration.
- Filtering: Hone in on a particular kernel, gpu-id, and/or dispatch-id via post-process filtering.
Run omniperf analyze -h for more details.
Demo
- To begin, generate a high-level analysis report utilizing Omniperf's
-b(a.k.a.--block) flag.
$ omniperf analyze -p workloads/vcopy/MI200/ -b 2
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = cli
[analysis] deriving Omniperf metrics...
--------------------------------------------------------------------------------
0. Top Stats
0.1 Top Kernels
╒════╤══════════════════════════════════════════╤═════════╤═══════════╤════════════╤══════════════╤════════╕
│ │ Kernel_Name │ Count │ Sum(ns) │ Mean(ns) │ Median(ns) │ Pct │
╞════╪══════════════════════════════════════════╪═════════╪═══════════╪════════════╪══════════════╪════════╡
│ 0 │ vecCopy(double*, double*, double*, int, │ 1.00 │ 20160.00 │ 20160.00 │ 20160.00 │ 100.00 │
│ │ int) [clone .kd] │ │ │ │ │ │
╘════╧══════════════════════════════════════════╧═════════╧═══════════╧════════════╧══════════════╧════════╛
0.2 Dispatch List
╒════╤═══════════════╤══════════════════════════════════════════════════════════╤══════════╕
│ │ Dispatch_ID │ Kernel_Name │ GPU_ID │
╞════╪═══════════════╪══════════════════════════════════════════════════════════╪══════════╡
│ 0 │ 0 │ vecCopy(double*, double*, double*, int, int) [clone .kd] │ 0 │
╘════╧═══════════════╧══════════════════════════════════════════════════════════╧══════════╛
--------------------------------------------------------------------------------
2. System Speed-of-Light
2.1 Speed-of-Light
╒═════════════╤═══════════════════════════╤═════════╤══════════════════╤══════════╤═══════════════╕
│ Metric_ID │ Metric │ Avg │ Unit │ Peak │ Pct of Peak │
╞═════════════╪═══════════════════════════╪═════════╪══════════════════╪══════════╪═══════════════╡
│ 2.1.0 │ VALU FLOPs │ 0.0 │ Gflop │ 22630.4 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.1 │ VALU IOPs │ 364.09 │ Giop │ 22630.4 │ 1.61 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.2 │ MFMA FLOPs (BF16) │ 0.0 │ Gflop │ 181043.2 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.3 │ MFMA FLOPs (F16) │ 0.0 │ Gflop │ 181043.2 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.4 │ MFMA FLOPs (F32) │ 0.0 │ Gflop │ 45260.8 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.5 │ MFMA FLOPs (F64) │ 0.0 │ Gflop │ 45260.8 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.6 │ MFMA IOPs (Int8) │ 0.0 │ Giop │ 181043.2 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.7 │ Active CUs │ 70.0 │ Cus │ 104.0 │ 67.31 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.8 │ SALU Utilization │ 3.78 │ Pct │ 100.0 │ 3.78 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.9 │ VALU Utilization │ 5.4 │ Pct │ 100.0 │ 5.4 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.10 │ MFMA Utilization │ 0.0 │ Pct │ 100.0 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.11 │ VMEM Utilization │ 1.08 │ Pct │ 100.0 │ 1.08 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.12 │ Branch Utilization │ 1.08 │ Pct │ 100.0 │ 1.08 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.13 │ VALU Active Threads │ 64.0 │ Threads │ 64.0 │ 100.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.14 │ IPC │ 0.21 │ Instr/cycle │ 5.0 │ 4.13 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.15 │ Wavefront Occupancy │ 2488.86 │ Wavefronts │ 3328.0 │ 74.79 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.16 │ Theoretical LDS Bandwidth │ 0.0 │ Gb/s │ 22630.4 │ 0.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.17 │ LDS Bank Conflicts/Access │ │ Conflicts/access │ 32.0 │ │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.18 │ vL1D Cache Hit Rate │ 50.0 │ Pct │ 100.0 │ 50.0 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.19 │ vL1D Cache BW │ 1664.41 │ Gb/s │ 11315.2 │ 14.71 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.20 │ L2 Cache Hit Rate │ 35.74 │ Pct │ 100.0 │ 35.74 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.21 │ L2 Cache BW │ 1296.31 │ Gb/s │ 3481.6 │ 37.23 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.22 │ L2-Fabric Read BW │ 416.52 │ Gb/s │ 1638.4 │ 25.42 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.23 │ L2-Fabric Write BW │ 292.3 │ Gb/s │ 1638.4 │ 17.84 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.24 │ L2-Fabric Read Latency │ 262.85 │ Cycles │ │ │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.25 │ L2-Fabric Write Latency │ 307.4 │ Cycles │ │ │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.26 │ sL1D Cache Hit Rate │ 99.82 │ Pct │ 100.0 │ 99.82 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.27 │ sL1D Cache BW │ 208.05 │ Gb/s │ 6092.8 │ 3.41 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.28 │ L1I Hit Rate │ 99.91 │ Pct │ 100.0 │ 99.91 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.29 │ L1I BW │ 208.05 │ Gb/s │ 6092.8 │ 3.41 │
├─────────────┼───────────────────────────┼─────────┼──────────────────┼──────────┼───────────────┤
│ 2.1.30 │ L1I Fetch Latency │ 20.86 │ Cycles │ │ │
╘═════════════╧═══════════════════════════╧═════════╧══════════════════╧══════════╧═══════════════╛
...
- Use
--list-metricsto generate a list of available metrics for inspection
$ omniperf analyze -p workloads/vcopy/MI200/ --list-metrics gfx90a
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = cli
[analysis] deriving Omniperf metrics...
0 -> Top Stats
1 -> System Info
2 -> System Speed-of-Light
2.1 -> Speed-of-Light
2.1.0 -> VALU FLOPs
2.1.1 -> VALU IOPs
2.1.2 -> MFMA FLOPs (BF16)
2.1.3 -> MFMA FLOPs (F16)
2.1.4 -> MFMA FLOPs (F32)
2.1.5 -> MFMA FLOPs (F64)
2.1.6 -> MFMA IOPs (Int8)
2.1.7 -> Active CUs
2.1.8 -> SALU Utilization
2.1.9 -> VALU Utilization
2.1.10 -> MFMA Utilization
2.1.11 -> VMEM Utilization
2.1.12 -> Branch Utilization
2.1.13 -> VALU Active Threads
2.1.14 -> IPC
2.1.15 -> Wavefront Occupancy
2.1.16 -> Theoretical LDS Bandwidth
2.1.17 -> LDS Bank Conflicts/Access
2.1.18 -> vL1D Cache Hit Rate
2.1.19 -> vL1D Cache BW
2.1.20 -> L2 Cache Hit Rate
2.1.21 -> L2 Cache BW
2.1.22 -> L2-Fabric Read BW
2.1.23 -> L2-Fabric Write BW
2.1.24 -> L2-Fabric Read Latency
2.1.25 -> L2-Fabric Write Latency
2.1.26 -> sL1D Cache Hit Rate
2.1.27 -> sL1D Cache BW
2.1.28 -> L1I Hit Rate
2.1.29 -> L1I BW
2.1.30 -> L1I Fetch Latency
...
- Choose your own customized subset of metrics with
-b(a.k.a.--block), or build your own config following config_template. Below shows how to generate a report containing only metric 2 (a.k.a. System Speed-of-Light).
$ omniperf analyze -p workloads/vcopy/MI200/ -b 2
--------
Analyze
--------
--------------------------------------------------------------------------------
0. Top Stat
╒════╤══════════════════════════════════════════╤═════════╤═══════════╤════════════╤══════════════╤════════╕
│ │ KernelName │ Count │ Sum(ns) │ Mean(ns) │ Median(ns) │ Pct │
╞════╪══════════════════════════════════════════╪═════════╪═══════════╪════════════╪══════════════╪════════╡
│ 0 │ vecCopy(double*, double*, double*, int, │ 1 │ 20000.00 │ 20000.00 │ 20000.00 │ 100.00 │
│ │ int) [clone .kd] │ │ │ │ │ │
╘════╧══════════════════════════════════════════╧═════════╧═══════════╧════════════╧══════════════╧════════╛
--------------------------------------------------------------------------------
2. System Speed-of-Light
╒═════════╤═══════════════════════════╤═══════════════════════╤══════════════════╤════════════════════╤════════════════════════╕
│ Index │ Metric │ Value │ Unit │ Peak │ PoP │
╞═════════╪═══════════════════════════╪═══════════════════════╪══════════════════╪════════════════════╪════════════════════════╡
│ 2.1.0 │ VALU FLOPs │ 0.0 │ Gflop │ 22630.4 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.1 │ VALU IOPs │ 367.0016 │ Giop │ 22630.4 │ 1.6217194570135745 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.2 │ MFMA FLOPs (BF16) │ 0.0 │ Gflop │ 90521.6 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.3 │ MFMA FLOPs (F16) │ 0.0 │ Gflop │ 181043.2 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.4 │ MFMA FLOPs (F32) │ 0.0 │ Gflop │ 45260.8 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.5 │ MFMA FLOPs (F64) │ 0.0 │ Gflop │ 45260.8 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.6 │ MFMA IOPs (Int8) │ 0.0 │ Giop │ 181043.2 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.7 │ Active CUs │ 74 │ Cus │ 104 │ 71.15384615384616 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.8 │ SALU Util │ 4.016057506716307 │ Pct │ 100 │ 4.016057506716307 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.9 │ VALU Util │ 5.737225009594725 │ Pct │ 100 │ 5.737225009594725 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.10 │ MFMA Util │ 0.0 │ Pct │ 100 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.11 │ VALU Active Threads/Wave │ 64.0 │ Threads │ 64 │ 100.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.12 │ IPC - Issue │ 1.0 │ Instr/cycle │ 5 │ 20.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.13 │ LDS BW │ 0.0 │ Gb/sec │ 22630.4 │ 0.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.14 │ LDS Bank Conflict │ │ Conflicts/access │ 32 │ │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.15 │ Instr Cache Hit Rate │ 99.91306912556854 │ Pct │ 100 │ 99.91306912556854 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.16 │ Instr Cache BW │ 209.7152 │ Gb/s │ 6092.8 │ 3.442016806722689 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.17 │ Scalar L1D Cache Hit Rate │ 99.81986908342313 │ Pct │ 100 │ 99.81986908342313 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.18 │ Scalar L1D Cache BW │ 209.7152 │ Gb/s │ 6092.8 │ 3.442016806722689 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.19 │ Vector L1D Cache Hit Rate │ 50.0 │ Pct │ 100 │ 50.0 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.20 │ Vector L1D Cache BW │ 1677.7216 │ Gb/s │ 11315.199999999999 │ 14.82714932126697 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.21 │ L2 Cache Hit Rate │ 35.55067615693325 │ Pct │ 100 │ 35.55067615693325 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.22 │ L2-Fabric Read BW │ 419.8496 │ Gb/s │ 1638.4 │ 25.6255859375 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.23 │ L2-Fabric Write BW │ 293.9456 │ Gb/s │ 1638.4 │ 17.941015625 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.24 │ L2-Fabric Read Latency │ 256.6482321288385 │ Cycles │ │ │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.25 │ L2-Fabric Write Latency │ 317.2264255699014 │ Cycles │ │ │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.26 │ Wave Occupancy │ 1821.723057333852 │ Wavefronts │ 3328 │ 54.73927455931046 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.27 │ Instr Fetch BW │ 4.174722306564298e-08 │ Gb/s │ 3046.4 │ 1.3703789084047721e-09 │
├─────────┼───────────────────────────┼───────────────────────┼──────────────────┼────────────────────┼────────────────────────┤
│ 2.1.28 │ Instr Fetch Latency │ 21.729248046875 │ Cycles │ │ │
╘═════════╧═══════════════════════════╧═══════════════════════╧══════════════════╧════════════════════╧════════════════════════╛
Some cells may be blank indicating a missing/unavailable hardware counter or NULL value
- Optimize application, iterate, and re-profile to inspect performance changes.
- Redo a comprehensive analysis with Omniperf CLI at any milestone or at the end.
More options
-
Single run
$ omniperf analyze -p workloads/vcopy/MI200/ -
List top kernels and dispatches
$ omniperf analyze -p workloads/vcopy/MI200/ --list-stats -
List metrics
$ omniperf analyze -p workloads/vcopy/MI200/ --list-metrics gfx90a -
Show "System Speed-of-Light" and "CS_Busy" blocks only
$ omniperf analyze -p workloads/vcopy/MI200/ -b 2 5.1.0Users can filter single metric or the whole hardware component by its id. In this case, 1 is the id for "system speed of light" and 5.1.0 the id for metric "GPU Busy Cycles". -
Filter kernels
First, list the top kernels in your application using
--list-stats.$ omniperf analyze -p workloads/vcopy/MI200/ --list-stats Analysis mode = cli [analysis] deriving Omniperf metrics... -------------------------------------------------------------------------------- Detected Kernels (sorted descending by duration) ╒════╤══════════════════════════════════════════════╕ │ │ Kernel_Name │ ╞════╪══════════════════════════════════════════════╡ │ 0 │ vecCopy(double*, double*, double*, int, int) │ ╘════╧══════════════════════════════════════════════╛ -------------------------------------------------------------------------------- Dispatch list ╒════╤═══════════════╤══════════════════════════════════════════════╤══════════╕ │ │ Dispatch_ID │ Kernel_Name │ GPU_ID │ ╞════╪═══════════════╪══════════════════════════════════════════════╪══════════╡ │ 0 │ 0 │ vecCopy(double*, double*, double*, int, int) │ 0 │ ╘════╧═══════════════╧══════════════════════════════════════════════╧══════════╛Second, select the index of the kernel you would like to filter (i.e. vecCopy(double*, double*, double*, int, int) [clone .kd] at index 0). Then, use this index to apply the filter via
-k/--kernels.$ omniperf analyze -p workloads/vcopy/MI200/ -k 0 Analysis mode = cli [analysis] deriving Omniperf metrics... -------------------------------------------------------------------------------- 0. Top Stats 0.1 Top Kernels ╒════╤══════════════════════════════════════════╤═════════╤═══════════╤════════════╤══════════════╤════════╤═════╕ │ │ Kernel_Name │ Count │ Sum(ns) │ Mean(ns) │ Median(ns) │ Pct │ S │ ╞════╪══════════════════════════════════════════╪═════════╪═══════════╪════════════╪══════════════╪════════╪═════╡ │ 0 │ vecCopy(double*, double*, double*, int, │ 1.00 │ 18560.00 │ 18560.00 │ 18560.00 │ 100.00 │ * │ │ │ int) │ │ │ │ │ │ │ ╘════╧══════════════════════════════════════════╧═════════╧═══════════╧════════════╧══════════════╧════════╧═════╛ ... ...You will see your filtered kernel(s) indicated by an asterisk in the Top Stats table -
Baseline comparison
omniperf analyze -p workload1/path/ -p workload2/path/OR
omniperf analyze -p workload1/path/ -k 0 -p workload2/path/ -k 1
GUI Analysis
Web-based GUI
Features
Omniperf's standalone GUI analyzer is a lightweight web page that can be generated directly from the command-line. This option is provided as an alternative for users wanting to explore profiling results graphically, but without the additional setup requirements or server-side overhead of Omniperf's detailed Grafana interface option. The standalone GUI analyzer is provided as simple Flask application allowing users to view results from within a web browser.
Note that the standalone GUI analyzer publishes a web interface on port 8050 by default.
On production HPC systems where profiling jobs run
under the auspices of a resource manager, additional SSH tunneling
between the desired web browser host (e.g. login node or remote workstation) and compute host may be
required. Alternatively, users may find it more convenient to download
profiled workloads to perform analysis on their local system.
See [FAQ](faq.md) for more details on SSH tunneling.
Usage
To launch the standalone GUI, include the --gui flag with your desired analysis command. For example:
$ omniperf analyze -p workloads/vcopy/MI200/ --gui
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = web_ui
[analysis] deriving Omniperf metrics...
Dash is running on http://0.0.0.0:8050/
* Serving Flask app 'rocprof_compute_analyze.analysis_webui' (lazy loading)
* Environment: production
WARNING: This is a development server. Do not use it in a production deployment.
Use a production WSGI server instead.
* Debug mode: off
* Running on all addresses (0.0.0.0)
WARNING: This is a development server. Do not use it in a production deployment.
* Running on http://127.0.0.1:8050
* Running on http://10.228.33.172:8050 (Press CTRL+C to quit)
At this point, users can then launch their web browser of choice and go to http://localhost:8050/ to see an analysis page.
To launch the web application on a port other than 8050, include an optional port argument:
`--gui <desired port>`
When no filters are applied, users will see five basic sections derived from their application's profiling data:
- Memory Chart Analysis
- Empirical Roofline Analysis
- Top Stats (Top Kernel Statistics)
- System Info
- System Speed-of-Light
To dive deeper, use the top drop down menus to isolate particular kernel(s) or dispatch(s). You will then see the web page update with metrics specific to the filter you have applied.
Once you have applied a filter, you will also see several additional sections become available with detailed metrics specific to that area of AMD hardware. These detailed sections mirror the data displayed in Omniperf's Grafana interface.
Grafana-based GUI
Features
The Omniperf Grafana GUI Analyzer supports the following features to facilitate MI GPU performance profiling and analysis:
- System and Hardware Component (Hardware Block) Speed-of-Light (SOL)
- Multiple normalization options, including per-cycle, per-wave, per-kernel and per-second.
- Baseline comparisons
- Regex based Dispatch ID filtering
- Roofline Analysis
- Detailed performance counters and metrics per hardware component, e.g.,
- Command Processor - Fetch (CPF) / Command Processor - Controller (CPC)
- Workgroup Manager (SPI)
- Shader Sequencer (SQ)
- Shader Sequencer Controller (SQC)
- L1 Address Processing Unit, a.k.a. Texture Addresser (TA) / L1 Backend Data Processing Unit, a.k.a. Texture Data (TD)
- L1 Cache (TCP)
- L2 Cache (TCC) (both aggregated and per-channel perf info)
Speed-of-Light
Speed-of-light panels are provided at both the system and per hardware component level to help diagnosis performance bottlenecks. The performance numbers of the workload under testing are compared to the theoretical maximum, (e.g. floating point operations, bandwidth, cache hit rate, etc.), to indicate the available room to further utilize the hardware capability.
Multi Normalization
Multiple performance number normalizations are provided to allow performance inspection within both HW and SW context. The following normalizations are permitted:
- per cycle
- per wave
- per kernel
- per second
Baseline Comparison
Omniperf enables baseline comparison to allow checking A/B effect. Currently baseline comparison is limited to the same SoC. Cross comparison between SoCs is in development.
For both the Current Workload and the Baseline Workload, one can independently setup the following filters to allow fine grained comparisons:
- Workload Name
- GPU ID filtering (multi-selection)
- Kernel Name filtering (multi-selection)
- Dispatch ID filtering (Regex filtering)
- Omniperf Panels (multi-selection)
Regex based Dispatch ID filtering
Omniperf enables Regular Expression (regex), a standard Linux string matching syntax, based dispatch ID filtering to flexibly choose the kernel invocations. One may refer to Regex Numeric Range Generator, to generate typical number ranges.
For example, if one wants to inspect Dispatch Range from 17 to 48, inclusive, the corresponding regex is : (1[7-9]|[23]\d|4[0-8]). The generated expression can be copied over for filtering.
Incremental Profiling
Omniperf supports incremental profiling to significantly speed up performance analysis.
Refer to Hardware Component Filtering section for this command.
By default, the entire application is profiled to collect performance counters for all hardware blocks, giving a complete view of where the workload stands in terms of performance optimization opportunities and bottlenecks.
After that one may focus on only a few hardware components, (e.g., L1 Cache or LDS) to closely check the effect of software optimizations, without performing application replay for all other hardware components. This saves lots of compute time. In addition, the prior profiling results for other hardware components are not overwritten. Instead, they can be merged during the import to piece together the system view.
Color Coding
The uniform color coding is applied to most visualizations (bars, table, diagrams etc). Typically, Yellow color means over 50%, while Red color mean over 90% percent, for easy inspection.
Global Variables and Configurations
Grafana GUI Import
The omniperf database --import option imports the raw profiling data to Grafana's backend MongoDB database. This step is only required for Grafana GUI based performance analysis.
Default username and password for MongoDB (to be used in database mode) are as follows:
- Username: temp
- Password: temp123
Each workload is imported to a separate database with the following naming convention:
omniperf_<team>_<database>_<soc>
e.g., omniperf_asw_vcopy_mi200.
When using database mode, be sure to tailor the connection options to the machine hosting your sever-side instance. Below is the sample command to import the vcopy profiling data, lets assuming our host machine is called "dummybox".
$ omniperf database --help
usage:
omniperf database <interaction type> [connection options]
-------------------------------------------------------------------------------
Examples:
omniperf database --import -H pavii1 -u temp -t asw -w workloads/vcopy/mi200/
omniperf database --remove -H pavii1 -u temp -w omniperf_asw_sample_mi200
-------------------------------------------------------------------------------
Help:
-h, --help show this help message and exit
General Options:
-v, --version show program's version number and exit
-V, --verbose Increase output verbosity (use multiple times for higher levels)
-s, --specs Print system specs.
Interaction Type:
-i, --import Import workload to Omniperf DB
-r, --remove Remove a workload from Omniperf DB
Connection Options:
-H , --host Name or IP address of the server host.
-P , --port TCP/IP Port. (DEFAULT: 27018)
-u , --username Username for authentication.
-p , --password The user's password. (will be requested later if it's not set)
-t , --team Specify Team prefix.
-w , --workload Specify name of workload (to remove) or path to workload (to import)
--kernel-verbose Specify Kernel Name verbose level 1-5. Lower the level, shorter the kernel name. (DEFAULT: 5) (DISABLE: 5)
omniperf import for vcopy:
$ omniperf database --import -H dummybox -u temp -t asw -w workloads/vcopy/mi200/
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Pulling data from /home/auser/repos/omniperf/sample/workloads/vcopy/MI200
The directory exists
Found sysinfo file
KernelName shortening enabled
Kernel name verbose level: 2
Password:
Password received
-- Conversion & Upload in Progress --
0%| | 0/11 [00:00<?, ?it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_IFETCH_LEVEL.csv
9%|█████████████████▉ | 1/11 [00:00<00:01, 8.53it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/pmc_perf.csv
18%|███████████████████████████████████▊ | 2/11 [00:00<00:01, 6.99it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_INST_LEVEL_SMEM.csv
27%|█████████████████████████████████████████████████████▋ | 3/11 [00:00<00:01, 7.90it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_LEVEL_WAVES.csv
36%|███████████████████████████████████████████████████████████████████████▋ | 4/11 [00:00<00:00, 8.56it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_INST_LEVEL_LDS.csv
45%|█████████████████████████████████████████████████████████████████████████████████████████▌ | 5/11 [00:00<00:00, 9.00it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_INST_LEVEL_VMEM.csv
55%|███████████████████████████████████████████████████████████████████████████████████████████████████████████▍ | 6/11 [00:00<00:00, 9.24it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/sysinfo.csv
64%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▎ | 7/11 [00:00<00:00, 9.37it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/roofline.csv
82%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████▏ | 9/11 [00:00<00:00, 12.60it/s]/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/timestamps.csv
100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 11/11 [00:00<00:00, 11.05it/s]
9 collections added.
Workload name uploaded
-- Complete! --
Omniperf Panels
Overview
There are currently 18 main panel categories available for analyzing the compute workload performance. Each category contains several panels for close inspection of the system performance.
- Kernel Statistics
- Kernel time histogram
- Top Ten bottleneck kernels
- System Speed-of-Light
- Speed-of-Light
- System Info table
- Memory Chart Analysis
- Roofline Analysis
- FP32/FP64
- FP16/INT8
- Command Processor
- Command Processor - Fetch (CPF)
- Command Processor - Controller (CPC)
- Workgroup Manager or Shader Processor Input (SPI)
- SPI Stats
- SPI Resource Allocations
- Wavefront Launch
- Wavefront Launch Stats
- Wavefront runtime stats
- per-SE Wavefront Scheduling performance
- Wavefront Lifetime
- Wavefront lifetime breakdown
- per-SE wavefront life (average)
- per-SE wavefront life (histogram)
- Wavefront Occupancy
- per-SE wavefront occupancy
- per-CU wavefront occupancy
- Compute Unit - Instruction Mix
- per-wave Instruction mix
- per-wave VALU Arithmetic instruction mix
- per-wave MFMA Arithmetic instruction mix
- Compute Unit - Compute Pipeline
- Speed-of-Light: Compute Pipeline
- Arithmetic OPs count
- Compute pipeline stats
- Memory latencies
- Local Data Share (LDS)
- Speed-of-Light: LDS
- LDS stats
- Instruction Cache
- Speed-of-Light: Instruction Cache
- Instruction Cache Accesses
- Constant Cache
- Speed-of-Light: Constant Cache
- Constant Cache Accesses
- Constant Cache - L2 Interface stats
- Texture Address and Texture Data
- Texture Address (TA)
- Texture Data (TD)
- L1 Cache
- Speed-of-Light: L1 Cache
- L1 Cache Accesses
- L1 Cache Stalls
- L1 - L2 Transactions
- L1 - UTCL1 Interface stats
- L2 Cache
- Speed-of-Light: L2 Cache
- L2 Cache Accesses
- L2 - EA Transactions
- L2 - EA Stalls
- L2 Cache Per Channel Performance
- Per-channel L2 Hit rate
- Per-channel L1-L2 Read requests
- Per-channel L1-L2 Write Requests
- Per-channel L1-L2 Atomic Requests
- Per-channel L2-EA Read requests
- Per-channel L2-EA Write requests
- Per-channel L2-EA Atomic requests
- Per-channel L2-EA Read latency
- Per-channel L2-EA Write latency
- Per-channel L2-EA Atomic latency
- Per-channel L2-EA Read stall (I/O, GMI, HBM)
- Per-channel L2-EA Write stall (I/O, GMI, HBM, Starve)
Most panels are designed around a specific hardware component block to thoroughly understand its behavior. Additional panels, including custom panels, could also be added to aid the performance analysis.
System Info Panel
:alt: System Info
:figclass: figure
:align: center
System details logged from host machine.
Kernel Statistics
Kernel Time Histogram
:alt: Kernel Time Histogram
:figclass: figure
:align: center
Mapping application kernel launches to execution duration.
Top Bottleneck Kernels
:alt: Top Bottleneck Kernels
:figclass: figure
:align: center
Top N kernels and relevant statistics. Sorted by total duration.
Top Bottleneck Dispatches
:alt: Top Bottleneck Dispatches
:figclass: figure
:align: center
Top N kernel dispatches and relevant statistics. Sorted by total duration.
Current and Baseline Dispatch IDs (Filtered)
:alt: Current and Baseline Dispatch IDs
:figclass: figure
:align: center
List of all kernel dispatches.
System Speed-of-Light
:alt: System Speed-of-Light
:figclass: figure
:align: center
Key metrics from various sections of Omniperf’s profiling report.
Memory Chart Analysis
Note: The Memory Chart Analysis support multiple normalizations. Due to the space limit, all transactions, when normalized to per-sec, default to unit of Billion transactions per second.
:alt: Memory Chart Analysis
:figclass: figure
:align: center
A graphical representation of performance data for memory blocks on the GPU.
Empirical Roofline Analysis
:alt: Roofline Analysis
:figclass: figure
:align: center
Visualize achieved performance relative to a benchmarked peak performance.
Command Processor
Command Processor Fetcher
:alt: Command Processor Fetcher
:figclass: figure
:align: center
Fetches commands out of memory to hand them over to the Command Processor Fetcher (CPC) for processing
Command Processor Compute
:alt: Command Processor Compute
:figclass: figure
:align: center
The micro-controller running the command processing firmware that decodes the fetched commands, and (for kernels) passes them to the Workgroup Managers (SPIs) for scheduling.
Shader Processor Input (SPI)
SPI Stats
:alt: SPI Stats
:figclass: figure
:align: center
TODO: Add caption after merge
SPI Resource Allocation
:alt: SPI Resource Allocation
:figclass: figure
:align: center
TODO: Add caption after merge
Wavefront
Wavefront Launch Stats
:alt: Wavefront Launch Stats
:figclass: figure
:align: center
General information about the kernel launch.
Wavefront Runtime Stats
:alt: Wavefront Runtime Stats
:figclass: figure
:align: center
High-level overview of the execution of wavefronts in a kernel.
Compute Unit - Instruction Mix
Instruction Mix
:alt: Instruction Mix
:figclass: figure
:align: center
Breakdown of the various types of instructions executed by the user’s kernel, and which pipelines on the Compute Unit (CU) they were executed on.
VALU Arithmetic Instruction Mix
:alt: VALU Arithmetic Instruction Mix
:figclass: figure
:align: center
The various types of vector instructions that were issued to the vector arithmetic logic unit (VALU).
MFMA Arithmetic Instruction Mix
:alt: MFMA Arithmetic Instruction Mix
:figclass: figure
:align: center
The types of Matrix Fused Multiply-Add (MFMA) instructions that were issued.
VMEM Arithmetic Instruction Mix
:alt: VMEM Arithmetic Instruction Mix
:figclass: figure
:align: center
The types of vector memory (VMEM) instructions that were issued.
Compute Unit - Compute Pipeline
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
The number of floating-point and integer operations executed on the vector arithmetic logic unit (VALU) and Matrix Fused Multiply-Add (MFMA) units in various precisions.
Pipeline Stats
:alt: Pipeline Stats
:figclass: figure
:align: center
More detailed metrics to analyze the several independent pipelines found in the Compute Unit (CU).
Arithmetic Operations
:alt: Arithmetic Operations
:figclass: figure
:align: center
The total number of floating-point and integer operations executed in various precisions.
Local Data Share (LDS)
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
Key metrics for the Local Data Share (LDS) as a comparison with the peak achievable values of those metrics.
LDS Stats
:alt: LDS Stats
:figclass: figure
:align: center
More detailed view of the Local Data Share (LDS) performance.
Instruction Cache
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
Key metrics of the L1 Instruction (L1I) cache as a comparison with the peak achievable values of those metrics.
Instruction Cache Stats
:alt: Instruction Cache Stats
:figclass: figure
:align: center
More detail on the hit/miss statistics of the L1 Instruction (L1I) cache.
Scalar L1D Cache
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
Key metrics of the Scalar L1 Data (sL1D) cache as a comparison with the peak achievable values of those metrics.
Scalar L1D Cache Accesses
:alt: Scalar L1D Cache Accesses
:figclass: figure
:align: center
More detail on the types of accesses made to the Scalar L1 Data (sL1D) cache, and the hit/miss statistics.
Scalar L1D Cache - L2 Interface
:alt: Scalar L1D Cache - L2 Interface
:figclass: figure
:align: center
More detail on the data requested across the Scalar L1 Data (sL1D) cache <-> L2 interface.
Texture Address and Texture Data
Texture Addresser
:alt: Texture Addresser
:figclass: figure
:align: center
Metric specific to texture addresser (TA) which receives commands (e.g., instructions) and write/atomic data from the Compute Unit (CU), and coalesces them into fewer requests for the cache to process.
Texture Data
:alt: Texture Data
:figclass: figure
:align: center
Metrics specific to texture data (TD) which routes data back to the requesting Compute Unit (CU).
Vector L1 Data Cache
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
Key metrics of the vector L1 data (vL1D) cache as a comparison with the peak achievable values of those metrics.
L1D Cache Stalls
:alt: L1D Cache Stalls
:figclass: figure
:align: center
More detail on where vector L1 data (vL1D) cache is stalled in the pipeline, which may indicate performance limiters of the cache.
L1D Cache Accesses
:alt: L1D Cache Accesses
:figclass: figure
:align: center
The type of requests incoming from the cache frontend, the number of requests that were serviced by the vector L1 data (vL1D) cache, and the number & type of outgoing requests to the L2 cache.
L1D - L2 Transactions
:alt: L1D - L2 Transactions
:figclass: figure
:align: center
A more granular look at the types of requests made to the L2 cache.
L1D Addr Translation
:alt: L1D Addr Translation
:figclass: figure
:align: center
After a vector memory instruction has been processed/coalesced by the address processing unit of the vector L1 data (vL1D) cache, it must be translated from a virtual to physical address. These metrics provide more details on the L1 Translation Lookaside Buffer (TLB) which handles this process.
L2 Cache
Speed-of-Light
:alt: Speed-of-Light
:figclass: figure
:align: center
Key metrics about the performance of the L2 cache, aggregated over all the L2 channels, as a comparison with the peak achievable values of those metrics.
L2 Cache Accesses
:alt: L2 Cache Accesses
:figclass: figure
:align: center
Incoming requests to the L2 cache from the vector L1 data (vL1D) cache and other clients (e.g., the sL1D and L1I caches).
L2 - Fabric Transactions
:alt: L2 - Fabric Transactions
:figclass: figure
:align: center
More detail on the flow of requests through Infinity Fabric™.
L2 - Fabric Interface Stalls
:alt: L2 - Fabric Interface Stalls
:figclass: figure
:align: center
A breakdown of what types of requests in a kernel caused a stall (e.g., read vs write), and to which locations (e.g., to the accelerator’s local memory, or to remote accelerators/CPUs).
L2 Cache Per Channel
Aggregate Stats
:alt: Aggregate Stats
:figclass: figure
:align: center
L2 Cache per channel performance at a glance. Metrics are aggregated over all available channels.

