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

Use eventset in roctxconnector (as in nvtxconnector) #219

Merged
merged 2 commits into from
Nov 20, 2023

Conversation

maartenarnst
Copy link
Contributor

This PR

  • updates roctxconnector by defining all the functions with the event set and the helper macros, like what is done in nvtxconnector. One of the interests of this approach is that it allows the callbacks to be set in a Kokkos program with get_event_set("roctx-connector",...) and then set_callbacks.

On the side, this PR also

  • introduces the namespace KokkosTools::ROCTXConnector
  • updates kokkosp_request_tool_settings such that fencing can be controlled with KOKKOS_TOOLS_GLOBALFENCES

Note that I've also tried to update the CMakeLists.txt for the roctxconnector to see if something could be done with a CMake target for roctx/roctracer, but I wasn't able to find such targets in the ROCm directories.

This is joint work with @romintomasetti.

@vlkale, @crtrott, would you have a moment to take a look, or refer to someone to take a look? Thanks in advance!

@vlkale
Copy link
Contributor

vlkale commented Nov 16, 2023

@maartenarnst @romintomasetti Thanks very much for this. I plan to review this later this week or early next.

From looking at your PR code changes, it makes sense to me and would be useful change.

profiling/nvtx-connector/Makefile Outdated Show resolved Hide resolved
target_include_directories(kp_roctx_connector PRIVATE ${ROCM_ROCTX_INCLUDE})
target_link_libraries(kp_roctx_connector PRIVATE ${ROCM_ROCTX_LIB})
target_include_directories(kp_roctx_connector PUBLIC ${ROCM_ROCTX_INCLUDE})
target_link_libraries(kp_roctx_connector PUBLIC ${ROCM_ROCTX_LIB})
Copy link
Member

Choose a reason for hiding this comment

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

Why did you change?
I can see how the linking would need some symbols to be private but not why the include directories would be needed downstream.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are leftovers from when I was trying to make the roctx-connector work with rocprof. I've reverted the change.

In fact, in my first tries, I used rocprof as follows:

rocprof --hip-trace --hsa-trace --roctx-trace ./a.out --kokkos-tools-libs=${KOKKOS_TOOLS_DIR}/lib/libkp_roctx_connector.so

That didn't work, in the sense that even though this command asks rocprof to use --roctx-trace, rocprof didn't include the markers in the results.json trace. I suspect that the reason may be that rocprof wants to see the executable linked to roctx64.so. That may not be the case when the connector is linked at runtime via dlsym. And so these leftovers came from attempts to make roctx64.so appear among the linked libraries.

profiling/roctx-connector/kp_roctx_connector.cpp Outdated Show resolved Hide resolved
Comment on lines +145 to +146
memset(&my_event_set, 0,
sizeof(my_event_set)); // zero any pointers not set here
Copy link
Member

Choose a reason for hiding this comment

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

Uggg. That thing really something that should be handled at construction.
I suspect value-initialization

EventSet my_event_set{};

does what you want.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed :) I used this piece of code because all connectors are currently doing it this way. It may be best to address the issue for all connectors in a separate PR? One way forward might be to provide default initialisers using = NULL for the function pointers in the declaration of the struct in Kokkos_Profiling_C_interface.h?

Copy link
Member

Choose a reason for hiding this comment

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

I used this piece of code because all connectors are currently doing it this way.

You are right. This is fine then.

And yes definitely fix elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

dalg24
dalg24 previously approved these changes Nov 17, 2023
@dalg24 dalg24 dismissed their stale review November 17, 2023 22:35

Not formatted properly (?) CI log is somewhat useless...

@maartenarnst
Copy link
Contributor Author

Hi @dalg24. Indeed, I've just improved the formatting. It seems the workflows need an approval to run. Would you have a moment to give an approval to see if it passes the formatting test now? Thanks.

@masterleinad
Copy link
Contributor

Hi @dalg24. Indeed, I've just improved the formatting. It seems the workflows need an approval to run. Would you have a moment to give an approval to see if it passes the formatting test now? Thanks.

@vlkale

@dalg24 dalg24 merged commit 62f3f02 into kokkos:develop Nov 20, 2023
7 checks passed
@vlkale
Copy link
Contributor

vlkale commented Nov 20, 2023

Hi @dalg24. Indeed, I've just improved the formatting. It seems the workflows need an approval to run. Would you have a moment to give an approval to see if it passes the formatting test now? Thanks.

@vlkale

@dalg24 cc @masterleinad thanks

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.

4 participants