AI/rocm-systems
2
0
Atdalīts 0
Kods Problēmas Izmaiņu pieprasījumi Darbības Pakotnes Projekti Laidieni Vikivietne Aktivitāte

Sync staging with mainline (#524)

Pārlūkot izejas kodu 
* 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>
Šī revīzija ir iekļauta:
Cole Ramos
2025-01-02 13:29:47 -08:00
revīziju iesūtīja GitHub
vecāks 71bc463921
revīzija 272e5b6e32
444 mainīti faili ar 9941 papildinājumiem un 9233 dzēšanām
Lejupielādēt ielāpa failu Lejupielādēt izmaiņu failu Izvērst visus failus Savērst visus failus
docs/archive/docs-1.x/.gitignore
+1 -1
Parādīt failu
@@ -2,4 +2,4 @@
/_build
/_doxygen
/.gitinfo
/omniperf.dox
/omniperf.dox
docs/archive/docs-1.x/Makefile
+1 -1
Parādīt failu
@@ -17,4 +17,4 @@ help:
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
docs/archive/docs-1.x/analysis.md
+25 -25
Parādīt failu
@@ -276,7 +276,7 @@ Analyze
```
- Customized profiling "System Speed-of-Light" and "CS_Busy" only
```shell
$ omniperf analyze -p workloads/vcopy/mi200/ -b 2 5.1.0
```
@@ -288,7 +288,7 @@ Analyze
First, list the top kernels in your application using `--list-kernels`.
```shell-session
$ omniperf analyze -p workloads/vcopy/mi200/ --list-kernels
--------
Analyze
--------
@@ -308,7 +308,7 @@ Analyze
```shell-session
$ omniperf -p workloads/vcopy/mi200/ -k 0
--------
Analyze
--------
@@ -324,17 +324,17 @@ Analyze
╘════╧══════════════════════════════════════════╧═════════╧═══════════╧════════════╧══════════════╧════════╧═════╛
... ...
```
> Note: You'll see your filtered kernel(s) indicated by a asterisk in the Top Stats table
- Baseline comparison
```shell
omniperf analyze -p workload1/path/ -p workload2/path/
```
> Note: You can also apply diffrent filters to each workload.
OR
```shell
omniperf analyze -p workload1/path/ -k 0 -p workload2/path/ -k 1
@@ -400,7 +400,7 @@ go to http://localhost:8050/ to see an analysis page.
![Standalone GUI Homepage](images/standalone_gui.png)
```{tip}
To launch the web application on a port other than 8050, include an optional port argument:
To launch the web application on a port other than 8050, include an optional port argument:
`--gui <desired port>`
```
@@ -429,7 +429,7 @@ The Omniperf Grafana GUI Analyzer supports the following features to facilitate
- System and IP-Block Speed-of-Light (SOL)
- Multiple normalization options, including per-cycle, per-wave, per-kernel and per-second.
- Baseline comparisons
- Baseline comparisons
- Regex based Dispatch ID filtering
- Roofline Analysis
- Detailed per IP Block performance counters and metrics
@@ -456,25 +456,25 @@ Multiple performance number normalizations are provided to allow performance ins
Omniperf enables baseline comparison to allow checking A/B effect. The current release limits the baseline comparison 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 comparions:
- Workload Name
- 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
This release enables regex based dispatch ID filtering to flexibly choose the kernel invocations. One may refer to [Regex Numeric Range Generator](https://3widgets.com/), to generate typical number ranges.
This release enables regex based dispatch ID filtering to flexibly choose the kernel invocations. One may refer to [Regex Numeric Range Generator](https://3widgets.com/), 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 express can be copied over for filtering.
##### Incremental Profiling
Omniperf supports incremental profiling to significantly speed up performance analysis.
> Refer to [*IP Block profiling*](https://rocm.github.io/omniperf/profiling.html#ip-block-profiling) section for this command.
> Refer to [*IP Block profiling*](https://rocm.github.io/omniperf/profiling.html#ip-block-profiling) section for this command.
By default, the entire application is profiled to collect perfmon counter for all IP blocks, giving a system level view of where the workload stands in terms of performance optimization opportunities and bottlenecks.
By default, the entire application is profiled to collect perfmon counter for all IP blocks, giving a system level view of where the workload stands in terms of performance optimization opportunities and bottlenecks.
After that one may focus on only a few IP blocks, (e.g., L1 Cache or LDS) to closely check the effect of software optimizations, without performing application replay for all other IP Blocks. This saves lots of compute time. In addition, the prior profiling results for other IP blocks are not overwritten. Instead, they can be merged during the import to piece together the system view.
After that one may focus on only a few IP blocks, (e.g., L1 Cache or LDS) to closely check the effect of software optimizations, without performing application replay for all other IP Blocks. This saves lots of compute time. In addition, the prior profiling results for other IP blocks 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.
@@ -484,7 +484,7 @@ The uniform color coding is applied to most visualizations (bars, table, diagram
![Grafana GUI Global Variables](images/global_variables.png)
#### 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.
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:
@@ -503,23 +503,23 @@ When using database mode, be sure to tailor the connection options to the machin
$ omniperf database --help
ROC Profiler: /usr/bin/rocprof
usage:
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
@@ -539,7 +539,7 @@ Connection Options:
-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)
-k , --kernelVerbose Specify Kernel Name verbose level 1-5.
-k , --kernelVerbose Specify Kernel Name verbose level 1-5.
Lower the level, shorter the kernel name. (DEFAULT: 2) (DISABLE: 5)
```
@@ -547,11 +547,11 @@ Connection Options:
```shell-session
$ omniperf database --import -H dummybox -u temp -t asw -w workloads/vcopy/mi200/
ROC Profiler: /usr/bin/rocprof
--------
Import Profiling Results
--------
Pulling data from /home/amd/xlu/test/workloads/vcopy/mi200
The directory exists
Found sysinfo file
docs/archive/docs-1.x/conf.py
+7 -6
Parādīt failu
@@ -8,19 +8,20 @@
# -- Path setup --------------------------------------------------------------
import subprocess as sp
import sys
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
# documentation root, use str(Path(<rel_path>).absolute().resolve()) to make it absolute, like shown here.
#
import os
import sys
import subprocess as sp
from pathlib import Path
sys.path.insert(0, os.path.abspath(".."))
sys.path.insert(0, str(Path("..").absolute().resolve()))
repo_version = "unknown"
# Determine short version by file in repo
if os.path.isfile("./VERSION"):
if Path("./VERSION").is_file():
with open("./VERSION") as f:
repo_version = f.readline().strip()
docs/archive/docs-1.x/faq.md
+4 -4
Parādīt failu
@@ -12,7 +12,7 @@ In order to interact with the Grafana GUI you must sync data with the MongoDB ba
Simply pass the directory of your desired workload like so,
```shell
$ omniperf database --import -w <path-to-results> -H <hostname> -u <username> -t <team-name>
$ omniperf database --import -w <path-to-results> -H <hostname> -u <username> -t <team-name>
```
**2. python ast error: 'Constant' object has no attribute 'kind'**
@@ -44,12 +44,12 @@ This pop up will appear
Local clients
- Forwarded Port: [PORT]
Remote Server
- Remote Server: localhost
- Remote Port: [PORT]
SSH Server
- SSH server: Name of the server one is connecting to
- SSH login: Username to login to the server
- SSH port: 22
- SSH port: 22
docs/archive/docs-1.x/getting_started.md
+5 -5
Parādīt failu
@@ -9,7 +9,7 @@
## Quickstart
1. **Launch & Profile the target application with the command line profiler**
The command line profiler launches the target application, calls the rocProfiler API, and collects profile results for the specified kernels, dispatches, and/or IP blocks. If not specified, Omniperf will default to collecting all available counters for all kernels/dispatches launched by the user's executable.
To collect the default set of data for all kernels in the target application, launch, e.g.:
@@ -19,7 +19,7 @@
The app runs, each kernel is launched, and profiling results are generated. By default, results are written to (e.g.,) ./workloads/vcopy_data (configurable via the `-n` argument). To collect all requested profile information, it may be required to replay kernels multiple times.
2. **Customize data collection**
Options are available to specify for which kernels/metrics data should be collected.
Note that filtering can be applied either in the profiling or analysis stage, however filtering at during profiling collection will often speed up your overall profiling run time.
@@ -34,7 +34,7 @@
```
3. **Analyze at the command line**
After generating a local output folder (./workloads/\<name>), the command line tool can also be used to quickly interface with profiling results. View different metrics derived from your profiled results and get immediate access all metrics organized by IP block.
If no kernel, dispatch, or ipblock filters are applied at this stage, analysis will be reflective of the entirety of the profiling data.
@@ -42,7 +42,7 @@
To interact with profiling results from a different session, users just provide the workload path. `-p`/`--path` enables users to analyze existing profiling data in the Omniperf CLI.
4. **Analyze in the Grafana GUI**
To conduct a more in-depth analysis of profiling results we recommend users utilize the Omniperf Grafana GUI. To interact with profiling results, users must import their data to the MongoDB instance included in the Omniperf dockerfile.
To interact with Grafana GUI data, stored in the Omniperf DB, users can enter ***database*** mode. For example:
@@ -90,4 +90,4 @@ Standalone roofline analysis | profile | `--name`, `--roof-only`, `-- <profile_c
Import a workload to database | database | `--import`, `--host`, `--username`, `--workload`, `--team`
Remove a workload from database | database | `--remove`, `--host`, `--username`, `--workload`, `--team`
Launch standalone GUI from CLI | analyze | `--path`, `--gui`
Interact with profiling results from CLI | analyze | `--path`
Interact with profiling results from CLI | analyze | `--path`
docs/archive/docs-1.x/high_level_design.md
+1 -2
Parādīt failu
@@ -10,7 +10,7 @@ The [Omniperf](https://github.com/ROCm/omniperf) Tool is architecturally compose
- **Omniperf Profiling**: Acquire raw performance counters via application replay based on the [rocProfiler](https://rocm.docs.amd.com/projects/rocprofiler/en/latest/rocprof.html). The counters are stored in a comma-seperated value, for further analyis. A set of MI200 specific micro benchmarks are also run to acquire the hierarchical roofline data. The roofline model is not available on earlier accelerators.
- **Omniperf Grafana Analyzer**:
- **Omniperf Grafana Analyzer**:
- *Grafana database import*: All raw performance counters are imported into the backend MongoDB database for Grafana GUI analysis and visualization. Compatibility of previously generated data between Omniperf versions is not necessarily guarenteed.
- *Grafana GUI Analyzer*: A Grafana dashboard is designed to retrieve the raw counters info from the backend database. It also creates the relevant performance metrics and visualization.
- **Omniperf Standalone GUI Analyzer**: A standalone GUI is provided to enable performance analysis without importing data into the backend database.
@@ -18,4 +18,3 @@ The [Omniperf](https://github.com/ROCm/omniperf) Tool is architecturally compose
![Omniperf Architectual Diagram](images/omniperf_server_vs_client_install.png)
> Note: To learn more about the client vs. server model of Omniperf and our install process please see the [Deployment section](./installation.md) of the docs.
docs/archive/docs-1.x/installation.md
+2 -3
Parādīt failu
@@ -33,7 +33,7 @@ Omniperf client-side requires the following basic software dependencies prior to
In addition, Omniperf leverages a number of Python packages that are
documented in the top-level `requirements.txt` file. These must be
installed prior to Omniperf configuration.
installed prior to Omniperf configuration.
The recommended procedure for Omniperf usage is to install into a shared file system so that multiple users can access the final installation. The following steps illustrate how to install the necessary python dependencies using [pip](https://packaging.python.org/en/latest/) and Omniperf into a shared location controlled by the `INSTALL_DIR` environment variable.
@@ -167,7 +167,7 @@ Once you've decided which machine you'd like to use to host the Grafana and Mong
### 1) Install MongoDB Utils
Omniperf uses [mongoimport](https://www.mongodb.com/docs/database-tools/mongoimport/) to upload data to Grafana's backend database. Install for Ubuntu 20.04 is as follows:
```bash
```bash
$ wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu2004-x86_64-100.6.1.deb
$ sudo apt install ./mongodb-database-tools-ubuntu2004-x86_64-100.6.1.deb
```
@@ -240,4 +240,3 @@ After a workload has been successfully uploaded, you should be able to select it
![Selecting Grafana workload](images/grafana_workload_selection.png)
For more information on how to use the Grafana interface for anlysis please see the [Grafana section](./analysis.md#grafana-based-gui) in the Analyze Mode tab.
docs/archive/docs-1.x/introduction.md
+2 -3
Parādīt failu
@@ -15,8 +15,8 @@ MI Performance Profiler ([Omniperf](https://github.com/ROCm/omniperf)) is a syst
## Features
The Omniperf tool performs system profiling based on all available hardware counters for the target accelerator. It provides high level performance analysis features including System Speed-of-Light, IP block Speed-of-Light, Memory Chart Analysis, Roofline Analysis, Baseline Comparisons, and more...
Both command line analysis and GUI analysis are supported.
Both command line analysis and GUI analysis are supported.
Detailed Feature List:
- MI100 support
@@ -54,4 +54,3 @@ Detailed Feature List:
| MI100 | Supported |
| MI200 | Supported |
| MI300 | In development |
docs/archive/docs-1.x/profiling.md
+12 -12
Parādīt failu
@@ -138,21 +138,21 @@ RPL: output dir '/tmp/rpl_data_230411_165021_26406'
RPL: result dir '/tmp/rpl_data_230411_165021_26406/input0_results_230411_165021'
Finished allocating vectors on the CPU
ROCProfiler: input from "/tmp/rpl_data_230411_165021_26406/input0.xml"
gpu_index =
kernel =
range =
gpu_index =
kernel =
range =
3 metrics
SQ_INSTS_SMEM, SQ_INST_LEVEL_SMEM, SQ_ACCUM_PREV_HIRES
Finished allocating vectors on the GPU
Finished copying vectors to the GPU
sw thinks it moved 1.000000 KB per wave
sw thinks it moved 1.000000 KB per wave
Total threads: 1048576, Grid Size: 4096 block Size:256, Wavefronts:16384:
Launching the kernel on the GPU
Finished executing kernel
Finished copying the output vector from the GPU to the CPU
Releasing GPU memory
Releasing CPU memory
... ...
ROCPRofiler: 1 contexts collected, output directory /tmp/rpl_data_220527_130317_1787038/input_results_220527_130317
File 'workloads/vcopy/mi200/timestamps.csv' is generating
@@ -321,14 +321,14 @@ RPL: output dir '/tmp/rpl_data_230411_170300_29696'
RPL: result dir '/tmp/rpl_data_230411_170300_29696/input0_results_230411_170300'
Finished allocating vectors on the CPU
ROCProfiler: input from "/tmp/rpl_data_230411_170300_29696/input0.xml"
gpu_index =
gpu_index =
kernel = vecCopy
... ...
```
#### Dispatch Filtering
Dispatch filtering is based on the *global* dispatch index of kernels in a run.
Dispatch filtering is based on the *global* dispatch index of kernels in a run.
The following example profiles only the 0th dispatched kernel in execution of the application:
```shell-session
@@ -358,8 +358,8 @@ RPL: output dir '/tmp/rpl_data_230411_170356_30314'
RPL: result dir '/tmp/rpl_data_230411_170356_30314/input0_results_230411_170356'
Finished allocating vectors on the CPU
ROCProfiler: input from "/tmp/rpl_data_230411_170356_30314/input0.xml"
gpu_index =
kernel =
gpu_index =
kernel =
range = 0
...
```
@@ -367,7 +367,7 @@ ROCProfiler: input from "/tmp/rpl_data_230411_170356_30314/input0.xml"
### Standalone Roofline
If you're only interested in generating roofline analysis data try using `--roof-only`. This will only collect counters relevent to roofline, as well as generate a standalone .pdf output of your roofline plot.
If you're only interested in generating roofline analysis data try using `--roof-only`. This will only collect counters relevent to roofline, as well as generate a standalone .pdf output of your roofline plot.
Standalone Roofline Options:
@@ -422,4 +422,4 @@ drwxrwxr-x 2 colramos colramos 4096 Apr 11 17:16 perfmon
```
A sample *empirRoof_gpu-ALL_fp32.pdf* looks something like this:
![Sample Standalone Roof Plot](images/sample-roof-plot.png)
![Sample Standalone Roof Plot](images/sample-roof-plot.png)
docs/archive/docs-2.x/.gitignore
+1 -1
Parādīt failu
@@ -2,4 +2,4 @@
/_build
/_doxygen
/.gitinfo
/omniperf.dox
/omniperf.dox
docs/archive/docs-2.x/analysis.md
+36 -36
Parādīt failu
@@ -28,17 +28,17 @@ Run `omniperf analyze -h` for more details.
### Demo
1) To begin, generate a high-level analysis report utilizing Omniperf's `-b` (a.k.a. `--block`) flag.
1) To begin, generate a high-level analysis report utilizing Omniperf's `-b` (a.k.a. `--block`) flag.
```shell-session
$ omniperf analyze -p workloads/vcopy/MI200/ -b 2
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = cli
[analysis] deriving Omniperf metrics...
@@ -135,12 +135,12 @@ Analysis mode = cli
```shell-session
$ omniperf analyze -p workloads/vcopy/MI200/ --list-metrics gfx90a
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = cli
[analysis] deriving Omniperf metrics...
@@ -289,7 +289,7 @@ Some cells may be blank indicating a missing/unavailable hardware counter or NUL
```
- __Show "System Speed-of-Light" and "CS_Busy" blocks only__
```shell
$ omniperf analyze -p workloads/vcopy/MI200/ -b 2 5.1.0
```
@@ -303,7 +303,7 @@ Some cells may be blank indicating a missing/unavailable hardware counter or NUL
First, list the top kernels in your application using `--list-stats`.
```shell-session
$ omniperf analyze -p workloads/vcopy/MI200/ --list-stats
Analysis mode = cli
[analysis] deriving Omniperf metrics...
@@ -329,7 +329,7 @@ Some cells may be blank indicating a missing/unavailable hardware counter or NUL
```shell-session
$ omniperf analyze -p workloads/vcopy/MI200/ -k 0
Analysis mode = cli
[analysis] deriving Omniperf metrics...
@@ -344,14 +344,14 @@ Some cells may be blank indicating a missing/unavailable hardware counter or NUL
╘════╧══════════════════════════════════════════╧═════════╧═══════════╧════════════╧══════════════╧════════╧═════╛
... ...
```
```{note}
You will see your filtered kernel(s) indicated by an asterisk in the Top Stats table
```
- __Baseline comparison__
```shell
omniperf analyze -p workload1/path/ -p workload2/path/
```
@@ -396,12 +396,12 @@ To launch the standalone GUI, include the `--gui` flag with your desired analysi
```shell-session
$ omniperf analyze -p workloads/vcopy/MI200/ --gui
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Analysis mode = web_ui
[analysis] deriving Omniperf metrics...
@@ -426,7 +426,7 @@ go to http://localhost:8050/ to see an analysis page.
![Standalone GUI Homepage](images/standalone_gui.png)
```{tip}
To launch the web application on a port other than 8050, include an optional port argument:
To launch the web application on a port other than 8050, include an optional port argument:
`--gui <desired port>`
```
@@ -455,7 +455,7 @@ The Omniperf Grafana GUI Analyzer supports the following features to facilitate
- 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
- Baseline comparisons
- Regex based Dispatch ID filtering
- Roofline Analysis
- Detailed performance counters and metrics per hardware component, e.g.,
@@ -482,7 +482,7 @@ Multiple performance number normalizations are provided to allow performance ins
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
- Workload Name
- GPU ID filtering (multi-selection)
- Kernel Name filtering (multi-selection)
- Dispatch ID filtering (Regex filtering)
@@ -498,7 +498,7 @@ Omniperf supports incremental profiling to significantly speed up performance an
> Refer to [*Hardware Component Filtering*](profiling.md#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.
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.
@@ -510,7 +510,7 @@ The uniform color coding is applied to most visualizations (bars, table, diagram
![Grafana GUI Global Variables](images/global_variables.png)
#### 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.
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:
@@ -527,23 +527,23 @@ When using database mode, be sure to tailor the connection options to the machin
```shell-session
$ omniperf database --help
usage:
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
@@ -571,14 +571,14 @@ Connection Options:
```shell-session
$ 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
docs/archive/docs-2.x/conf.py
+7 -6
Parādīt failu
@@ -8,19 +8,20 @@
# -- Path setup --------------------------------------------------------------
import subprocess as sp
import sys
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
# documentation root, use str(Path(<rel_path>).absolute().resolve()) to make it absolute, like shown here.
#
import os
import sys
import subprocess as sp
from pathlib import Path
sys.path.insert(0, os.path.abspath(".."))
sys.path.insert(0, str(Path("..").absolute().resolve()))
repo_version = "unknown"
# Determine short version by file in repo
if os.path.isfile("./VERSION"):
if Path("./VERSION").is_file():
with open("./VERSION") as f:
repo_version = f.readline().strip()
docs/archive/docs-2.x/faq.md
+3 -3
Parādīt failu
@@ -12,7 +12,7 @@ In order to interact with the Grafana GUI you must sync data with the MongoDB ba
Simply pass the directory of your desired workload like so,
```shell
$ omniperf database --import -w <path-to-results> -H <hostname> -u <username> -t <team-name>
$ omniperf database --import -w <path-to-results> -H <hostname> -u <username> -t <team-name>
```
**2. python ast error: 'Constant' object has no attribute 'kind'**
@@ -56,11 +56,11 @@ This pop up will appear
Local clients
- Forwarded Port: [PORT]
Remote Server
- Remote Server: localhost
- Remote Port: [PORT]
SSH Server
- SSH server: Name of the server one is connecting to
- SSH login: Username to login to the server
docs/archive/docs-2.x/getting_started.md
+2 -2
Parādīt failu
@@ -17,7 +17,7 @@
$ omniperf profile -n vcopy_data -- ./vcopy -n 1048576 -b 256
```
The app runs, each kernel is launched, and profiling results are generated. By default, results are written to a subdirectory with your accelerator's name e.g., ./workloads/vcopy_data/MI200/ (where name is configurable via the `-n` argument).
```{note}
To collect all requested profile information, it may be required to replay kernels multiple times.
```
@@ -86,7 +86,7 @@ Modes change the fundamental behavior of the Omniperf command line tool. Dependi
$ omniperf database --help
```
### Global Options
The Omniperf command line tool has a set of 'global' options that are available across all modes.
The Omniperf command line tool has a set of 'global' options that are available across all modes.
| Argument | Description |
| :----------------- | :---------------------------------------------------------------- |
docs/archive/docs-2.x/high_level_design.md
+1 -1
Parādīt failu
@@ -10,7 +10,7 @@ The [Omniperf](https://github.com/ROCm/omniperf) Tool is architecturally compose
- **Omniperf Profiling**: Acquire raw performance counters via application replay based on [rocProf](https://rocm.docs.amd.com/projects/rocprofiler/en/latest/rocprof.html). The counters are stored in a comma-separated format, for further analysis. A set of MI200 specific micro benchmarks are also run to acquire the hierarchical roofline data. The roofline model is not available on earlier accelerators.
- **Omniperf Grafana Analyzer**:
- **Omniperf Grafana Analyzer**:
- *Grafana database import*: All raw performance counters are imported into the backend MongoDB database for Grafana GUI analysis and visualization. Compatibility of previously generated data between Omniperf versions is not necessarily guaranteed.
- *Grafana GUI Analyzer*: A Grafana dashboard is designed to retrieve the raw counters info from the backend database. It also creates the relevant performance metrics and visualization.
- **Omniperf Standalone GUI Analyzer**: A standalone GUI is provided to enable performance analysis without importing data into the backend database.
docs/archive/docs-2.x/images/amd-header-logo.svg
+1 -1
Parādīt failu
@@ -1 +1 @@
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 139.72 33.32"><defs><style>.cls-1{fill:#fff;}</style></defs><title>AMD-logo-white-v2</title><path class="cls-1" d="M33,31.14H25.21l-2.37-5.72H9.92L7.76,31.14H.14L11.78,2.26h8.34Zm-16.89-22L11.83,20.39h8.89Z" transform="translate(-0.14 -0.03)"/><path class="cls-1" d="M61.1,2.26h6.27V31.14h-7.2v-18l-7.79,9.06h-1.1L43.49,13.1v18h-7.2V2.26h6.27L51.83,13Z" transform="translate(-0.14 -0.03)"/><path class="cls-1" d="M85.61,2.26c10.54,0,16,6.56,16,14.48,0,8.3-5.25,14.4-16.77,14.4H72.86V2.26ZM80.06,25.85h4.7c7.24,0,9.4-4.91,9.4-9.15,0-5-2.67-9.15-9.48-9.15H80.06Z" transform="translate(-0.14 -0.03)"/><polygon class="cls-1" points="130.64 9.08 115.75 9.08 106.68 0 139.72 0 139.72 33.05 130.64 23.97 130.64 9.08"/><polygon class="cls-1" points="115.74 23.98 115.74 10.9 106.4 20.24 106.4 33.33 119.48 33.33 128.82 23.98 115.74 23.98"/></svg>
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 139.72 33.32"><defs><style>.cls-1{fill:#fff;}</style></defs><title>AMD-logo-white-v2</title><path class="cls-1" d="M33,31.14H25.21l-2.37-5.72H9.92L7.76,31.14H.14L11.78,2.26h8.34Zm-16.89-22L11.83,20.39h8.89Z" transform="translate(-0.14 -0.03)"/><path class="cls-1" d="M61.1,2.26h6.27V31.14h-7.2v-18l-7.79,9.06h-1.1L43.49,13.1v18h-7.2V2.26h6.27L51.83,13Z" transform="translate(-0.14 -0.03)"/><path class="cls-1" d="M85.61,2.26c10.54,0,16,6.56,16,14.48,0,8.3-5.25,14.4-16.77,14.4H72.86V2.26ZM80.06,25.85h4.7c7.24,0,9.4-4.91,9.4-9.15,0-5-2.67-9.15-9.48-9.15H80.06Z" transform="translate(-0.14 -0.03)"/><polygon class="cls-1" points="130.64 9.08 115.75 9.08 106.68 0 139.72 0 139.72 33.05 130.64 23.97 130.64 9.08"/><polygon class="cls-1" points="115.74 23.98 115.74 10.9 106.4 20.24 106.4 33.33 119.48 33.33 128.82 23.98 115.74 23.98"/></svg>
Blakus Pārvelkot Pārklājoši

Pirms

Platums:  |  Augstums:  |  Izmērs: 924 B

Pēc

Platums:  |  Augstums:  |  Izmērs: 925 B

docs/archive/docs-2.x/images/fabric.svg
+1 -1
Parādīt failu
@@ -684,7 +684,7 @@
y="240.85156"
id="tspan43344"><tspan
style="text-align:center;text-anchor:middle"
id="tspan43342">Atomic
id="tspan43342">Atomic
</tspan></tspan><tspan
x="134.80859"
y="260.85156"
Blakus Pārvelkot Pārklājoši

Pirms

Platums:  |  Augstums:  |  Izmērs: 33 KiB

Pēc

Platums:  |  Augstums:  |  Izmērs: 33 KiB

docs/archive/docs-2.x/images/ldsbandwidth.svg
+626 -626
Parādīt failu
Failā izmaiņas netiks attēlotas, jo tās ir par lielu Ielādēt izmaiņas
Blakus Pārvelkot Pārklājoši

Pirms

Platums:  |  Augstums:  |  Izmērs: 86 KiB

Pēc

Platums:  |  Augstums:  |  Izmērs: 85 KiB

docs/archive/docs-2.x/images/ldsconflictrate.svg
+577 -577
Parādīt failu
Failā izmaiņas netiks attēlotas, jo tās ir par lielu Ielādēt izmaiņas
Blakus Pārvelkot Pārklājoši

Pirms

Platums:  |  Augstums:  |  Izmērs: 31 KiB

Pēc

Platums:  |  Augstums:  |  Izmērs: 30 KiB

docs/archive/docs-2.x/images/ldsconflicts.svg
+566 -566
Parādīt failu
Failā izmaiņas netiks attēlotas, jo tās ir par lielu Ielādēt izmaiņas
Blakus Pārvelkot Pārklājoši

Pirms

Platums:  |  Augstums:  |  Izmērs: 34 KiB

Pēc

Platums:  |  Augstums:  |  Izmērs: 34 KiB

docs/archive/docs-2.x/installation.md
+1 -2
Parādīt failu
@@ -181,7 +181,7 @@ Once you have decided which machine you would like to use to host the Grafana an
#### Install MongoDB Utils
Omniperf uses [mongoimport](https://www.mongodb.com/docs/database-tools/mongoimport/) to upload data to Grafana's backend database. Install for Ubuntu 20.04 is as follows:
```bash
```bash
$ wget https://fastdl.mongodb.org/tools/db/mongodb-database-tools-ubuntu2004-x86_64-100.6.1.deb
$ sudo apt install ./mongodb-database-tools-ubuntu2004-x86_64-100.6.1.deb
```
@@ -265,4 +265,3 @@ After a workload has been successfully uploaded, you should be able to select it
![Selecting Grafana workload](images/grafana_workload_selection.png)
For more information on how to use the Grafana interface for analysis please see the [Grafana section](./analysis.md#grafana-based-gui) in the Analyze Mode tab.
docs/archive/docs-2.x/performance_model.md
+14 -15
Parādīt failu
@@ -96,7 +96,7 @@ The SIMDs in the [VALU](valu) are connected to the LDS in pairs (see above).
Only one SIMD per pair may issue an LDS instruction at a time, but both pairs may issue concurrently.
On CDNA accelerators, the LDS contains 32 banks and each bank is 4B wide.
The LDS is designed such that each bank can be read from/written to/atomically updated every cycle, for a total throughput of 128B/clock ([GCN Crash Course](https://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah), slide 40).
The LDS is designed such that each bank can be read from/written to/atomically updated every cycle, for a total throughput of 128B/clock ([GCN Crash Course](https://www.slideshare.net/DevCentralAMD/gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah), slide 40).
On each of the two ports to the SIMDs, 64B can be sent in each direction per cycle. So, a single wavefront, coming from one of the 2 SIMDs in a pair, can only get back 64B/cycle (16 lanes per cycle). The input port is shared between data and address and this can affect achieved bandwidth for different data sizes. For example, a 64-wide store where each lane is sending a 4B value takes 8 cycles (50% peak bandwidth) while a 64-wide store where each lane is sending a 16B value takes 20 cycles (80% peak bandwidth).
@@ -270,7 +270,7 @@ The wavefront runtime statistics gives a high-level overview of the execution of
```{list-table}
:header-rows: 1
:widths: 18 65 17
:widths: 18 65 17
:class: noscroll-table
* - Metric
- Description
@@ -1481,7 +1481,7 @@ The Scalar L1D speed-of-light chart shows some key metrics of the sL1D cache as
- Description
- Unit
* - Bandwidth
- The number of bytes looked up in the sL1D cache, as a percent of the peak theoretical bandwidth. Calculated as the ratio of sL1D requests over the [total sL1D cycles](TotalSL1DCycles).
- The number of bytes looked up in the sL1D cache, as a percent of the peak theoretical bandwidth. Calculated as the ratio of sL1D requests over the [total sL1D cycles](TotalSL1DCycles).
- Percent
* - Cache Hit Rate
- The percent of sL1D requests that hit{sup}`1` on a previously loaded line in the cache. Calculated as the ratio of the number of sL1D requests that hit over the number of all sL1D requests.
@@ -1601,7 +1601,7 @@ The L1 Instruction Cache speed-of-light chart shows some key metrics of the L1I
- Description
- Unit
* - Bandwidth
- The number of bytes looked up in the L1I cache, as a percent of the peak theoretical bandwidth. Calculated as the ratio of L1I requests over the [total L1I cycles](TotalL1ICycles).
- The number of bytes looked up in the L1I cache, as a percent of the peak theoretical bandwidth. Calculated as the ratio of L1I requests over the [total L1I cycles](TotalL1ICycles).
- Percent
* - Cache Hit Rate
- The percent of L1I requests that hit on a previously loaded line the cache. Calculated as the ratio of the number of L1I requests that hit{sup}`1` over the number of all L1I requests.
@@ -1822,10 +1822,10 @@ The command processor's metrics therefore are focused on reporting, e.g.:
- Percent of total cycles counted by the CPF-[L2](L2) interface where the CPF-L2 interface was active doing any work. The ratio of CPF-L2 busy cycles over total cycles counted by the CPF-L2.
- Percent
* - CPF-L2 Stall
- Percent of CPF-L2 busy cycles where the CPF-[L2](L2) interface was stalled for any reason.
- Percent of CPF-L2 busy cycles where the CPF-[L2](L2) interface was stalled for any reason.
- Percent
* - CPF-UTCL1 Stall
- Percent of CPF busy cycles where the CPF was stalled by address translation.
- Percent of CPF busy cycles where the CPF was stalled by address translation.
- Percent
```
@@ -1958,10 +1958,10 @@ Finally, the system speed-of-light summarizes some of the key metrics from vario
- The percent of sL1D requests that hit on a previously loaded line the cache. Calculated as the ratio of the number of sL1D requests that hit over the number of all sL1D requests.
- Percent
* - [sL1D](sL1D) Bandwidth
- The number of bytes looked up in the sL1D cache per unit time. This is also presented as a percent of the peak theoretical bandwidth achievable on the specific accelerator.
- The number of bytes looked up in the sL1D cache per unit time. This is also presented as a percent of the peak theoretical bandwidth achievable on the specific accelerator.
- GB/s
* - [L1I](L1I) Bandwidth
- The number of bytes looked up in the L1I cache per unit time. This is also presented as a percent of the peak theoretical bandwidth achievable on the specific accelerator.
- The number of bytes looked up in the L1I cache per unit time. This is also presented as a percent of the peak theoretical bandwidth achievable on the specific accelerator.
- GB/s
* - [L1I](L1I) Cache Hit Rate
- The percent of L1I requests that hit on a previously loaded line the cache. Calculated as the ratio of the number of L1I requests that hit over the number of all L1I requests.
@@ -2170,7 +2170,7 @@ These memory types include:
- Memory that will be cached by the accelerator, but may be invalidated by writes from remote devices at kernel boundaries / after software-driven synchronization events. On [MI2XX](2xxnote) accelerators, this corresponds to "coarse-grained" memory allocated locally to the accelerator, using e.g., the default `hipMalloc` allocator.
```
A good discussion of coarse and fine grained memory allocations and what type of memory is returned by various combinations of memory allocators, flags and arguments can be found in the [Crusher Quick-Start Guide](https://docs.olcf.ornl.gov/systems/crusher_quick_start_guide.html#floating-point-fp-atomic-operations-and-coarse-fine-grained-memory-allocations).
A good discussion of coarse and fine grained memory allocations and what type of memory is returned by various combinations of memory allocators, flags and arguments can be found in the [Crusher Quick-Start Guide](https://docs.olcf.ornl.gov/systems/crusher_quick_start_guide.html#floating-point-fp-atomic-operations-and-coarse-fine-grained-memory-allocations).
(profiling-with-omniperf)=
# Profiling with Omniperf by Example
@@ -2719,7 +2719,7 @@ $ omniperf analyze -p workloads/fine_grained_host_writes/mi200 -b 17.2.4 17.2.5
```
Here we notice a few changes in our request pattern:
- As expected, the requests have changed from 64B Reads to 64B Write requests (17.5.7),
- As expected, the requests have changed from 64B Reads to 64B Write requests (17.5.7),
- these requests are homed in on a "remote" destination (17.2.6, 17.5.9), as expected, and,
- these are also counted as a single Uncached Write request (17.5.6).
@@ -2978,7 +2978,7 @@ As discussed [previously](Flat_design), our `generic_write` kernel uses an addre
We also note that the `filter` parameter passed in as a kernel argument (see [example](https://github.com/ROCm/omniperf/blob/amd-mainline/sample/vmem.hip), or [design note](Flat_design)) is set to zero on the host, such that we always write to the 'local' (LDS) memory allocation `lds`.
Examining this kernel in the VMEM Instruction Mix table yields:
Examining this kernel in the VMEM Instruction Mix table yields:
```shell-session
$ omniperf analyze -p workloads/vmem/mi200/ --dispatch 2 -b 10.3 -n per_kernel
@@ -3749,7 +3749,7 @@ $ omniperf analyze -p workloads/ipc/mi200/ --dispatch 10 -b 11.2
```
Here we see that:
- both our IPC (11.2.0) and Issued IPC (11.2.1) are $\sim1.0$ as expected, and,
- both our IPC (11.2.0) and Issued IPC (11.2.1) are $\sim1.0$ as expected, and,
- the SALU Utilization (11.2.2) was nearly 100% as it was active for almost the entire kernel.
(VALU_Active_Threads)=
@@ -4034,7 +4034,7 @@ The bank conflict rate linearly increases with the number of work-items within a
(Occupancy_example)=
## Occupancy Limiters Example
## Occupancy Limiters Example
In this [example](https://github.com/ROCm/omniperf/blob/amd-mainline/sample/occupancy.hip), we will investigate the use of the resource allocation panel in the [Workgroup Manager](SPI)'s metrics section to determine occupancy limiters.
@@ -4180,7 +4180,7 @@ denotes the divide between `VGPRs` and `AGPRs`.
Next, we examine our wavefront occupancy (2.1.15), and see that we are reaching only $\sim50\%$ of peak occupancy.
As a result, we see that:
- We are not scheduling workgroups $\sim25\%$ of [total scheduler-pipe cycles](TotalPipeCycles) (6.2.1); recall from the discussion of the [Workgroup manager](SPI), 25\% is the maximum.
- The scheduler-pipe is stalled (6.2.2) from scheduling workgroups due to resource constraints for the same $\sim25\%$ of the time.
- The scheduler-pipe is stalled (6.2.2) from scheduling workgroups due to resource constraints for the same $\sim25\%$ of the time.
- And finally, $\sim91\%$ of those stalls are due to a lack of SIMDs with the appropriate number of VGPRs available (6.2.5).
That is, the reason we can't reach full occupancy is due to our VGPR usage, as expected!
@@ -4407,4 +4407,3 @@ Finally, we inspect the occupancy limiter metrics and see a roughly even split b
This is yet another reminder to view occupancy holistically.
While these metrics tell you why a workgroup cannot be scheduled, they do _not_ tell you what your occupancy was (consult wavefront occupancy) _nor_ whether increasing occupancy will be beneficial to performance.
docs/archive/docs-2.x/profiling.md
+24 -24
Parādīt failu
@@ -28,7 +28,7 @@ vcopy testing on GCD 0
Finished allocating vectors on the CPU
Finished allocating vectors on the GPU
Finished copying vectors to the GPU
sw thinks it moved 1.000000 KB per wave
sw thinks it moved 1.000000 KB per wave
Total threads: 1048576, Grid Size: 4096 block Size:256, Wavefronts:16384:
Launching the kernel on the GPU
Finished executing kernel
@@ -56,12 +56,12 @@ The following sample command profiles the *vcopy* workload.
```shell-session
$ omniperf profile --name vcopy -- ./vcopy -n 1048576 -b 256
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Omniperf version: 2.0.0
Profiler choice: rocprofv1
@@ -99,13 +99,13 @@ Collecting Performance Counters
|-> [rocprof] Finished copying the output vector from the GPU to the CPU
|-> [rocprof] Releasing GPU memory
|-> [rocprof] Releasing CPU memory
|-> [rocprof]
|-> [rocprof]
|-> [rocprof] ROCPRofiler: 1 contexts collected, output directory /tmp/rpl_data_240312_174329_692890/input0_results_240312_174329
|-> [rocprof] File '/home/auser/repos/omniperf/sample/workloads/vcopy/MI200/SQ_IFETCH_LEVEL.csv' is generating
|-> [rocprof]
|-> [rocprof]
[profiling] Current input file: /home/auser/repos/omniperf/sample/workloads/vcopy/MI200/perfmon/SQ_INST_LEVEL_LDS.txt
...
...
[roofline] Checking for roofline.csv in /home/auser/repos/omniperf/sample/workloads/vcopy/MI200
[roofline] No roofline data found. Generating...
@@ -147,7 +147,7 @@ GPU Device 3: Profiling...
To reduce verbosity of profiling output try the `--quiet` flag which will hide rocprofiler output and activate a progress bar.
```
You will notice two main stages in *default* Omniperf profiling.
You will notice two main stages in *default* Omniperf profiling.
1. The first stage collects all the counters needed for Omniperf analysis (omitting any filters you have provided).
@@ -158,7 +158,7 @@ In this document, we use the term System on Chip (SoC) to refer to a particular
- "MI200" for the AMD Instinct (tm) MI200 family of accelerators
- "MI100" for the AMD Instinct (tm) MI100 family of accelerators
- etc.
The SoC names are generated as a part of Omniperf, and do not _always_ distinguish between different accelerators in the same family (e.g., an AMD Instinct (tm) MI210 vs an MI250)
```{note}
@@ -208,12 +208,12 @@ The following example only gathers hardware counters for the Shader Sequencer (S
```shell-session
$ omniperf profile --name vcopy -b SQ TCC -- ./vcopy -n 1048576 -b 256
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
fname: pmc_cpc_perf: Skipped
fname: pmc_spi_perf: Skipped
@@ -252,12 +252,12 @@ The following example demonstrates profiling isolating the kernel matching subst
```shell-session
$ omniperf profile --name vcopy -k vecCopy -- ./vcopy -n 1048576 -b 256
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Omniperf version: 2.0.0
Profiler choice: rocprofv1
@@ -275,18 +275,18 @@ Collecting Performance Counters
```
#### Dispatch Filtering
Dispatch filtering is based on the *global* dispatch index of kernels in a run.
Dispatch filtering is based on the *global* dispatch index of kernels in a run.
The following example profiles only the first kernel dispatch in execution of the application (please note zero-based indexing):
```shell-session
$ omniperf profile --name vcopy -d 0 -- ./vcopy -n 1048576 -b 256
___ _ __
___ _ __
/ _ \ _ __ ___ _ __ (_)_ __ ___ _ __ / _|
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| | | | '_ ` _ \| '_ \| | '_ \ / _ \ '__| |_
| |_| | | | | | | | | | | |_) | __/ | | _|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
\___/|_| |_| |_|_| |_|_| .__/ \___|_| |_|
|_|
Omniperf version: 2.0.0
Profiler choice: rocprofv1
@@ -305,7 +305,7 @@ Collecting Performance Counters
### Standalone Roofline
If you are only interested in generating roofline analysis data try using `--roof-only`. This will only collect counters relevant to roofline, as well as generate a standalone .pdf output of your roofline plot.
If you are only interested in generating roofline analysis data try using `--roof-only`. This will only collect counters relevant to roofline, as well as generate a standalone .pdf output of your roofline plot.
Standalone Roofline Options: