ROCprofiler-SDK is an improved version of ROCm profiling tools that enables more efficient implementations and better thread safety while avoiding problems that plague the former implementations of ROCProfiler and ROCTracer.
Here are the distinct ROCprofiler-SDK features, which also highlight the improvements over ROCProfiler and ROCTracer:
The former implementations allow a tool to access any of the services provided by ROCProfiler or ROCTracer, such as API tracing and kernel tracing, by calling ``roctracer_init()`` when an ROCm runtime is initially loaded.
As the calling tool is not required to specify during initialization, the services it needs to use, the libraries must be effectively prepared for any service to be available anytime.
This behavior introduces unnecessary overhead and makes thread-safe data management difficult, as tools generally don't use all the available services.
For example, ROCTracer always installs wrappers around every runtime API and adds indirection overhead through the ROCTracer library to check for the current service configuration in a thread-safe manner.
ROCprofiler-SDK introduces `context` to solve the preceding issues. Contexts are effectively bundles of service configurations. ROCprofiler-SDK provides a single opportunity for a tool to create as many contexts as required.
A tool can group all services into one context, create one context per service, or choose a mix.
This change in the design allows ROCprofiler-SDK to be aware of the services that might be requested by a tool at any given time.
The design change empowers ROCprofiler-SDK to:
- Avoid unnecessary preparation for services that are never used. If no registered contexts request HSA API tracing, no wrappers need to be generated.
- Perform more extensive checks during service specification and inform a tool about potential issues early.
- Allow multiple tools to use certain services simultaneously.
- Improve thread safety without introducing parallel bottlenecks.
- Manage internal data and allocations more efficiently.
- For collecting HIP Runtime API Traces, e.g. public HIP API functions starting with 'hip' (i.e. hipSetDevice).
-
* - Granular tracing options
- HIP compiler trace
- *Not Available*
- *Not Available*
- `--hip-compiler-trace`
- For collecting HIP Compiler generated code Traces, e.g. HIP API functions starting with '__hip' (i.e. __hipRegisterFatBinary).
-
* - Granular tracing options
- HSA core API trace
- Part of `--hsa-trace` option
- Part of `--hsa-trace` option
- `--hsa-core-trace`
- New option for collecting only HSA API Traces (core API), e.g. HSA functions prefixed with only `hsa_` (i.e. hsa_init)
-
* - Granular tracing options
- HSA AMD trace
- Part of `--hsa-trace` option
- Part of `--hsa-trace` option
- `--hsa-amd-trace`
- For collecting HSA API Traces (AMD-extension API), e.g. HSA function prefixed with `hsa_amd_` (i.e. hsa_amd_coherency_get_type)
-
* - Granular tracing options
- HSA Image Extension trace
- Part of `--hsa-trace` option
- Part of `--hsa-trace` option
- `--hsa-image-trace`
- New option for collecting HSA API Traces (Image-extenson API), e.g. HSA functions prefixed with only `hsa_ext_image_` (i.e. hsa_ext_image_get_capability).
-
* - Granular tracing options
- HSA Finalizer trace
- Part of `--hsa-trace` option
- Part of `--hsa-trace` option
- `--hsa-finalizer-trace`
- New option for collecting HSA API Traces (Finalizer-extension API), e.g. HSA functions prefixed with only `hsa_ext_program_` (i.e. hsa_ext_program_create)
- New option for truncating the demangled kernel names
-
* - Kernel naming options
- Kernel Rename
- `--roctx-rename`
- *Not available*
- `--kernel-rename`
- New option to use region names defined by roctxRangePush/roctxRangePop regions to rename the kernels
-
* - Post-processing tracing options
- Statistics
- --stats
- *Not Available*
- --stats
- Statistics for the collected traces
-
* - Post-processing tracing options
- Summary
- *Not available*
- *Not available*
- `-S, --summary`
- New option to output a single summary of tracing data after the profiling session
- `rocprof` generated the post-processing step's summary, stats, JSON, and database files with much less information.
* - Post-processing tracing options
- Summary Per Domain
- *Not available*
- *Not available*
- `-D, --summary-per-domain`
- New option to output summary for each tracing domain after the profiling session
- `rocprof --stats` option had less number of domains in the summary reports than `rocprofv3`
* - Post-processing tracing options
- Summary Groups
- *Not available*
- *Not available*
- `--summary-groups REGULAR_EXPRESSION`
- New option to output a summary for each set of domains matching the regular expression, e.g. 'KERNEL_DISPATCH|MEMORY_COPY' will generate a summary from all the tracing data in the KERNEL_DISPATCH and MEMORY_COPY domains
-
* - Summary options
- Summary Output File
- *Not available*
- *Not available*
- `--summary-output-file SUMMARY_OUTPUT_FILE`
- New option to output summary to a file, stdout, or stderr (default: stderr)
-
* - Summary options
- Summary Units
- *Not available*
- *Not available*
- `-u , --summary-units`
- New option to output summary in desired time units {sec,msec,usec,nsec}
- | # Multiple output formats can be supported in single run.
| # OTF2 can visualize larger trace files compared to perfetto.
- The Perfetto UI does not accept the JSON output format produced by rocprofv3. Perfetto is dropping support for the JSON Chrome tracing format in favor of the binary Perfetto protobuf format (``.pftrace`` extension), which is supported by rocprofv3.
* - I/O options
- Counter Collection
- Supports input text and XML format
- Only supports input text format
- Input support for text, YAML and JSON formats
- | # Its not possible to check for valid text file. Hence rocprofv3 supports strongly typed input formats.
| # YAML and JSON formats are more readable and easy to maintain.
| # Allows flexibility to add more features for the tool input
- Users can specify multiple configurations, each defined by a triplet in the format `start_delay:collection_time:repeat`, with the ability to change the unit of time in the given configurations.
``rocprofv3`` has improved the accuracy of timing information by reducing the tool overhead required to collect data and reducing the interference to the timing of the kernel being measured. The result of this work is a reduction in variance of kernel times received for the same kernel execution and more accurate timing in general. These changes have not been backported (and will not be backported) to rocprofv1/v2, so there can be substantial (20%) differences in execution time reported by v1/v2 vs v3 for a single kernel execution. Over a large number of samples of the same kernel, the difference in average execution time is in the low single digit percentage time with a much tighter variance of results on rocprofv3. We have included testing in the test suite to verify the timing information outputted by rocprofv3 to ensure that the values we are returning are accurate.
``rocprofv3`` has a different default behavior than rocprofv1/v2 when being run without any option. The default behavior of rocprofv3 is to collect all available agents on the system and to output it in ``csv`` format. The default behavior of rocprofv1/v2 was to output the `kernel traces` in CSV format. In rocprofv3, kernel traces can be obtained by using ``--kernel-trace`` option.
