The documentation for rocprofiler-v1 indicates that the profiling scope can be controlled by "dispatch range" and "kernel name". Here, the "dispatch range" is an index or a range of indices of dispatch ranges. However, when using roctx markup, the ranges are labelled with strings by their names, and not with numbers by indices. Indeed, roctxRangeStart takes the name as input, and it returns the index, but this index is typically an internal number in the code, not accessible to the user.
Thus, a useful feature may be to provide the ability to control the profiling scope by passing the name of the roctx range.
The feature would be similar to --nvtx-include and --nvtx-exclude that can be passed to ncu on Cuda.
A related question is how the profiling scope should/can be controlled in rocprofiler-v2.
Suggestion Description
The documentation for
rocprofiler-v1indicates that the profiling scope can be controlled by "dispatch range" and "kernel name". Here, the "dispatch range" is an index or a range of indices of dispatch ranges. However, when usingroctxmarkup, the ranges are labelled with strings by their names, and not with numbers by indices. Indeed,roctxRangeStarttakes the name as input, and it returns the index, but this index is typically an internal number in the code, not accessible to the user.Thus, a useful feature may be to provide the ability to control the profiling scope by passing the name of the roctx range.
The feature would be similar to
--nvtx-includeand--nvtx-excludethat can be passed toncuon Cuda.A related question is how the profiling scope should/can be controlled in
rocprofiler-v2.Operating System
No response
GPU
No response
ROCm Component
No response