Add first pass of rocm kernel profiler - #10911
Conversation
|
Some background. The libroctracer api used to collect rocm execution is similar to cupti. However, it is a bit more rudimentary and requires more support code. That code ends up in every implementation. The code in this PR is based on a Kineto implementation I did which was in turn based on a standalone profiler I have done. What I have done is refactor the code into two pieces:
The ultimate goal here would be to use the RoctracerLogger across multiple projects. That way features and bug fixes can happen in one place. I will go back and refactor kineto to use RoctracerLogger (and an adapter). I'm not sure if it is practical to share the actual source file, ideas for that appreciated. |
|
Issues to resolve: API calls We will need to add an EventCategory, e.g. (SESSION_EVENT, NODE_EVENT, KERNEL_EVENT). Preference? API_EVENT? Kernel Name Demangling String Formatting |
| @@ -0,0 +1,194 @@ | |||
| // (c) Meta Platforms, Inc. and affiliates. Confidential and proprietary. | |||
There was a problem hiding this comment.
Pls make sure to have all file headers aligned.
There was a problem hiding this comment.
Yeah. This is one of the files we want to share between framework profilers. I'm wondering if we should just add the files as a submodule.
| : data(data), validSize(validSize) {} | ||
|
|
||
| ~RoctracerActivityBuffer() { | ||
| free(data); |
There was a problem hiding this comment.
I don't anticipate anyone reusing this structure, it is just a wrapper to make sure some malloc memory is freed. These will never be copied or moved. Just keeping it simple, no interest in copy semantics or blocking operator= or copy constructors.
There was a problem hiding this comment.
Then u should mark move/copy as deleted.
| } | ||
|
|
||
| // Allocated by malloc | ||
| uint8_t* data{nullptr}; |
There was a problem hiding this comment.
Ah yes, the horrid google style. Missed that one, and one other, thanks.
| bool invertMode() { return invert_; } | ||
| void setInvertMode(bool invert) { invert_ = invert; } | ||
| void add(std::string apiName); | ||
| void remove(std::string apiName); |
There was a problem hiding this comment.
Obviously not, fixed, thanks.
|
|
||
| //namespace profiling { | ||
|
|
||
| int32_t systemThreadId(); |
There was a problem hiding this comment.
There was a problem hiding this comment.
I tried to switch over to using the methods in logging.h but had issues with linking. Simple approach caused a failure at runtime to load the rocm_provider.so because the symbols couldn't be resolved. Pulling logging.cc into the rocm_provider caused a duplicated symbol. Couldn't spot an example in the cmake files of how to do this correctly. I lost interest at this point.
I am still using the original functions. End of day they are probably a bit faster as they are using tls to cache the pid,tid.
| private: | ||
| void addEventRecord(const roctracerRow &item, int64_t pstart, const std::initializer_list<std::pair<std::string, std::string>> &args, std::map<uint64_t, std::vector<EventRecord>> &event_map); | ||
|
|
||
| RoctracerLogger *d; |
There was a problem hiding this comment.
This is just indicating that it is emulating "d pointer" pattern, i.e. pimpl. I can't think of another name that would add any value. Whatever makes you happy.
| if (!singleton().externalCorrelationEnabled_) { | ||
| return; | ||
| } | ||
| t_externalIds[type].push_back(id); |
There was a problem hiding this comment.
This is a limitation of libroctracer. If we have roctracer pass back digest-style api calls (a buffer at a time like cupti does) then those pages lack the call arguments. So, as you can see, we are collecting the calls and args inline. Roctracer only generates external correlation events when using that page-at-time method. This is fine, my inline method is faster, gets the args, and can generate external correlation.
Unless you understand more about external correlation implementation than I do... your statement about "place an id on device" is a misconception. All that happens is that a mapping from internal correlation id to (one or more) external correlation ids is generated when the api call is made. The 'device' is running ops and tracking them by internal correlation id (that is shares with the generating api call), just like normal.
Because I have 'bitten the bullet' and I am doing inline collection I can implement external correlation here. Without using inline callbacks cupti would have to do this for me and deliver a bunch of records. My way is clearly faster, so it probably turned into an advantage.
|
I'm going to create a second PR with the cupti changes (api calls and name demangling). The cupti side will need to use demangle.cc and demangle.h (which are in providers/rocm right now). What is a good common location for those 2 files in your opinion? |
|
|
||
| //namespace onnxruntime { | ||
|
|
||
| //namespace profiling { |
Would u mind to merge the content of demangle.* into profiler_common.*? |
|
I'll attempt to link against the profiler_common code again. If I can get it to work I'll move the demangle into there. |
…pu buffer clearing.
|
So I half-missed your comment about moving demangle into profiler-common. I did put those files into into core/common, but that is not exactly what you asked. But I think I would have had an issue with what you asked: There is no profiler_common.cc, it is all declaration and it is in "onnxruntime/include/onnxruntime/core/common/profiler_common.h". So there is no place for the demangle implementation. So where would you want the demangle implementation added? |
You could create there be a profile_common.cc. |
|
Azure Pipelines successfully started running 9 pipeline(s). |
|
Azure Pipelines successfully started running 8 pipeline(s). |
|
Please fix "Python format (pull_request) " error, thx |
|
RandySheriffH (@RandySheriffH) - please have another look? thx |
|
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows WebAssembly CI Pipeline, orttraining-amd-gpu-ci-pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, onnxruntime-python-checks-ci-pipeline |
|
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux Nuphar CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline |
|
Azure Pipelines successfully started running 8 pipeline(s). |
|
Azure Pipelines successfully started running 9 pipeline(s). |
please fix this, otherwise it will block u from merging it, thx |
|
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows WebAssembly CI Pipeline, orttraining-amd-gpu-ci-pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, onnxruntime-python-checks-ci-pipeline |
|
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux Nuphar CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline |
|
Azure Pipelines successfully started running 8 pipeline(s). |
|
Azure Pipelines successfully started running 9 pipeline(s). |
|
please run "black" on your local machine, it will correct the format for you. |
|
This pull request fixes 5 alerts when merging 74084d2 into a972db0 - view on LGTM.com fixed alerts:
|
|
/azp run Linux CPU CI Pipeline, Linux CPU Minimal Build E2E CI Pipeline, Linux GPU CI Pipeline, Linux GPU TensorRT CI Pipeline, Linux Nuphar CI Pipeline, Linux OpenVINO CI Pipeline, MacOS CI Pipeline, ONNX Runtime Web CI Pipeline, onnxruntime-binary-size-checks-ci-pipeline |
|
/azp run Windows CPU CI Pipeline, Windows GPU CI Pipeline, Windows GPU TensorRT CI Pipeline, Windows WebAssembly CI Pipeline, orttraining-amd-gpu-ci-pipeline, orttraining-linux-ci-pipeline, orttraining-linux-gpu-ci-pipeline, orttraining-ortmodule-distributed, onnxruntime-python-checks-ci-pipeline |
|
Azure Pipelines successfully started running 9 pipeline(s). |
|
Azure Pipelines successfully started running 8 pipeline(s). |
|
Thank you for the contribution !! |



Description: Add a profiler to collect ROCm kernel and copy executions.
Motivation and Context
This will allow attribution of AMD gpu executions to ops.
No Issue yet?