-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ROCm component refactoring #49
Merged
gcongiu
merged 26 commits into
icl-utk-edu:master
from
gcongiu:2023.05.12_rocm-cmp-refactor
Oct 11, 2023
Merged
ROCm component refactoring #49
gcongiu
merged 26 commits into
icl-utk-edu:master
from
gcongiu:2023.05.12_rocm-cmp-refactor
Oct 11, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gcongiu
force-pushed
the
2023.05.12_rocm-cmp-refactor
branch
4 times, most recently
from
July 25, 2023 09:47
c28f680
to
2b37d82
Compare
gcongiu
force-pushed
the
2023.05.12_rocm-cmp-refactor
branch
6 times, most recently
from
September 8, 2023 13:22
35b7337
to
f63abb4
Compare
Errors associated with rocprofiler calls are assigned PAPI_EMISC, while errors caused by unexpected user actions (e.g. starting an eventset that is already running) are assigned PAPI_EINVAL. Everything that is not a memory allocation failure (PAPI_ENOMEM) is assigned the PAPI_ECMP error.
This guard was introduced when rocmtools was planned instead of rocprofiler V2.
Some functionality can be shared with other profiler versions, if and when these become available. Thus, it makes sense to extract such functionality from the specific profiler implementation and make it available to future profiler versions.
The rocm lock and the profiling mode variables need to be shared between the front-end and the back-end. The reason for the lock is that this has to be initialized by the front-end which is the only one with access to the required information. This lock design in PAPI is flawed as it is hard to extend.
gcongiu
force-pushed
the
2023.05.12_rocm-cmp-refactor
branch
from
October 9, 2023 17:38
3871cf6
to
60d30cc
Compare
adanalis
approved these changes
Oct 11, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Description
The rocm component enables multiple versions of the vendor profiling library to work correctly with PAPI. This is achieved by wrapping the rocprofiler calls with a new (more generic and simple) interface. The rocm component appropriately dispatches PAPI requests to the appropriate rocprofiler version through the wrapper (or dispatch) layer. Currently, the rocprofiler code contains functionalities (e.g., acquiring and releasing devices in multithreaded applications) that are not specific to the rocprofiler version and can be made available to future versions of rocprofiler. This PR restructures the rocm component code to extract common functionality and improve extendability of the component.
Author Checklist
Why this PR exists. Reference all relevant information, including background, issues, test failures, etc
Commits are self contained and only do one thing
Commits have a header of the form:
module: short description
Commits have a body (whenever relevant) containing a detailed description of the addressed problem and its solution
The PR needs to pass all the tests