Skip to content
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

rbt2.4 calc TSC once, fixes BW calcs #60

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

rbt2.4 calc TSC once, fixes BW calcs #60

wants to merge 1 commit into from

Conversation

srinivamd
Copy link

What
Add ROCM_HOME parameter to specify the ROCm installed root on cmake. For example, to configure build for ROCm 3.7.0 APIs/libraries, use:
cmake -DROCM_HOME=/opt/rocm-3.7.0
The default "/opt/rocm" will be used when ROCM_HOME is not specified.

Remove giant triple-nested loops chewing up CPU cycles when running benchmark and skewing timing of interrupts/signals causing erratic results on certain platforms. The TSCFreq calculation, which uses a huge loop is calculated once per run instead of for every iteration/transaction.
Calculating TSCFreq makes the rocm-bandwidth-test 2.4.0 run much faster!

Update version to 2.4.0

Why
Multiple ROCm releases can be installed on a system. Each ROCm release under their own top level directory, such as /opt/rocm-3.3.0, /opt/rocm-3.5.0, etc. It is important to set runpath when building applications to link with the specific ROCm version it is intended to, and load those specific versions of libraries at runtime as well to avoid impact of any incompatible changes in libraries/APIs.

How
Use ROCM_HOME to specify the top level ROCm installed directory. The cmake find_package uses it to find hsa-runtime64 cmake targets.

After building the applications, run
ldd rocm-bandwidth-test
to verify that the libraries are picked from the ROCM_HOME location.

At runtime, a user shall use LD_LIBRARY_PATH to direct loader if needed.

@srinivamd
Copy link
Author

@rerrabolu @ashutom could you please review and merge this soon so it can be picked up for the upcoming 3.7 release?

@@ -109,9 +109,15 @@ elseif("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -m32")
endif()

find_package(hsa-runtime64 REQUIRED
PATHS /opt/rocm
if (DEFINED ROCM_HOME)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add extra variables. To find hsa-runtime64-config.cmake from a path other than /opt/rocm, CMAKE_PREFIX_PATH can be used.
CMAKE_PREFIX_PATH="custom path for hsa"
This will function same was as ROCM_HOME="custom path for hsa or rocm"

Copy link
Author

@srinivamd srinivamd Aug 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to add extra variables

What is the optimization of you get out of "No need to add extra variables" or what is the downside? The CMAKE_PREFIX_PATH and other cmake defined paths have side-effects and using those variables to get what user wants cmake to do is incorrect application of those variables, which leads to more headaches.
Read https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html
CMAKE_PREFIX_PATH is to specify destination dir. That is not the purpose of the change here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you are referring here is CMAKE_INSTALL_PREFIX.

CMAKE_PREFIX_PATH gives a different purpose.

https://cmake.org/cmake/help/v3.0/variable/CMAKE_PREFIX_PATH.html

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, my mistake. But please see my comments on line 170+ as to avoid "deduction logic" and providing user-defined parameter to use with runpath, etc.
My changes allow DevOps and other cmake experts to continue to use CMAKE_PREFIX_PATH to do a find as well as simple users who want to specify the lcoation to use, and use that in runpath.

Comment on lines +90 to +91
// uint64_t CoarseTimestampUs();
// uint64_t MeasureTSCFreqHz();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be remove this commented code?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! How about the cleanup of comments be taken care of in the next change in the interest of time? Let's get this integrated so users can relying on RBT to generate correct results can get the fix and build and use RBT for performance tuning.

@@ -161,6 +167,10 @@ if( DEFINED ENV{ROCM_RPATH})
set ( CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-new-dtags -Wl,--rpath,$ENV{ROCM_RPATH}" )
endif()

if (DEFINED ROCM_HOME)
set ( CMAKE_EXE_LINKER_FLAGS "-Wl,--enable-new-dtags -Wl,--rpath,${ROCM_HOME}/hsa/lib:${ROCM_HOME}/lib64:${ROCM_HOME}/lib" )

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Path for hsa library is already known to the cmake from find_package(hsa_runtime64).
${hsa-runtime64_DIR} will give the path for /lib/cmake/hsa-runtime64
So it will be better to deduce the path from there rather than adding a new variable. That will ensure RPATH is the same as the one linked against.

Copy link
Author

@srinivamd srinivamd Aug 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it will be better to deduce the path..

No, @paulfreddy. The changes allow the user to specify the parameter value to use instead o relying on cmake crap to find stuff, and code in deduction paths in cmakefiles. This changes take a keep it simple approach, and leaves existing users/jenkins/devops who rely on cmake gymnastics for their environment to continue with them.
I had to trace cmake logic to figure what was going wrong with runpath settings - no one should have to go through that IMHO.
So, the user specifiable define parameter, just like compiler defines makes it easier to specify the parameters needed to generate the makefiles. IOW, relying on another packages cmake files, their relative locations, etc. to build an "application" is not "better" approach as it relies on cmake too much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants