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

CMake build system #131

Closed
wants to merge 92 commits into from
Closed

Conversation

mzuzek
Copy link

@mzuzek mzuzek commented Oct 30, 2021

Fixes #128

Summary

With this PR we enable building the tools with CMake. Caliper and Apex are connected as git submodules and can be built from source if no existing installation is found. In build, tools try to find Kokkos and propagate it's settings (e.g. enable CUDA support) to tools and TPLs. "Single library intefrace" is introduced which allows simple linking of all enabled tools and TPLs to client application.

Build: sample app CMake list file

find_package(Kokkos REQUIRED)
add_directory(kokkos-tools) # TODO: CMake install exports

add_executable(myapp source.cpp)

target_link_libraries(myapp Kokkos::kokkos kokkostools) # link all tools

Usage: sample app source code

#include <Kokkos_Core.hpp>
#include "kp_all.hpp"

int main(int argc, char *argv[])
{
  const char *profiler_name = "caliper";
  const char *profiler_config = "runtime-report(profile.kokkos)";

  auto eventSet = KokkosTools::get_event_set(profiler_name, profiler_config);
  Kokkos::Tools::Experimental::set_callbacks(eventSet);

  Kokkos::initialize(argc, argv);
  // ... run app ... //
  Kokkos::finalize();
  return 0;
}

Contents / Status

  • General:
    • CMake scripts to build tools;
    • Single library interface linking all tools and TPLs;
    • Fetch basic Kokkos settings in alternative scenarios:
      • 1. from existing installation (find_package(Kokkos) based on Kokkos_ROOT);
      • 2. from source if Kokkos is being built within same parent CMake project;
      • 3. skip option propagation if Kokkos is not available;
    • MPI support;
    • Basic Windows (MSVC) build support - with Caliper and VTune;
    • CMake exports for tools Installation;
    • Allow building each tool separately;
  • Building tools (for traditional runtime shared library connection):
    • Native tools: space-time-stack, chrome-tracing, simple-kernel-timer, simple-kernel-timer-json, memory-hwm-mpi, memory-usage, memory-events, memory-hwm and memory-hwm-mpi;
    • Native utilities: kernel-filter and kernel-logger;
    • TPL connectors: VTune, SystemTap, Variorum and PAPI;
    • TPLs: Caliper and Apex built from source (submodules) if no existing installation is detected;
    • TPLs: apollo (builtin-ml-library branch);
    • GPU profiler connectors:
  • Tools available via KokkosTools::get_event_set(profiler_name, profiler_config) single library interface:
    • All native tools;
    • TPL connectors: VTune, SystemTap and Variorum;
    • Caliper with configuration string support, requires WIP Caliper support for builtin Kokkos Tools (continued) LLNL/Caliper#402 branch;
    • Apex, PAPI connector and GPU connectors;
    • Native utilities (kernel-filter and kernel-logger) + implement std::vector/array overload of Kokkos::Tools::Experimental::set_callbacks() for registering multiple event sets ?
  • Documentation and examples:
    • Add example demonstrating single library interface;
    • Update ReadMe.md with instructions on how to configure and build tools with CMake;
  • Other / fixes:
    • Implement own tool to fetch parent path and replace cmake_path(GET ... PARENT_PATH ...) which requires CMake v3.20 ?

Future considerations:

  • connect timemory (like Caliper and Apex);
  • consider introducing lazy profiler initialization (kokkosp_init_library() called after Kokkos::initialize());

@mzuzek mzuzek changed the title Cmake build system CMake build system Oct 30, 2021
CMakeLists.txt Outdated
if(TARGET Kokkos::kokkos)
message(STATUS "Using Kokkos settings for KokkosTools (source: ${Kokkos_SOURCE_DIR})")
else()
message(WARNING "Not using Kokkos for tools configuration\n\tNote: using settings from installed is Kokkos not yet supported")
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, this is a really slick idea

Copy link
Contributor

Choose a reason for hiding this comment

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

Why would there be a Kokkos::Kokkos target w/o a find_package(Kokkos)?

Copy link
Contributor

Choose a reason for hiding this comment

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

In my app's CMakeLists.txt

add_subdirectory(kokkos) # defines the target
add_subdirectory(kokkos-tools)

Copy link
Contributor

Choose a reason for hiding this comment

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

That's not very clear, especially with the set(CMAKE_CXX_COMPILER ${Kokkos_CXX_COMPILER}) down below.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, could definitely use a comment. It's also more of a Lawrence Livermore-ism than something Sandia codes do today

Copy link
Author

Choose a reason for hiding this comment

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

I cleaned this up a bit (excuse messy draft). The idea is that:

  1. we check if Kokkos is built within same parent project - and before Tools, as in David's example above. Is there a better way than checking for TARGET Kokkos::kokkos ? In this case we're all set up with options, compiler and flags.
  2. we check for installed Kokkos in Kokkos_ROOT and extract all relevant settings from there.
  3. in case Kokkos is nowhere found, we might just built Tools alone (figuring reasonable option defaults) or error out.

Any suggestions appreciated (where's the slicky part ?)

@DavidPoliakoff
Copy link
Contributor

I like where you're starting with this. Also looping in @daboehme in case he has opinions about how we're playing with Caliper here

Copy link
Contributor

@jrmadsen jrmadsen left a comment

Choose a reason for hiding this comment

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

Just my thoughts

CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated
if(TARGET Kokkos::kokkos)
message(STATUS "Using Kokkos settings for KokkosTools (source: ${Kokkos_SOURCE_DIR})")
else()
message(WARNING "Not using Kokkos for tools configuration\n\tNote: using settings from installed is Kokkos not yet supported")
Copy link
Contributor

Choose a reason for hiding this comment

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

Why would there be a Kokkos::Kokkos target w/o a find_package(Kokkos)?

CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
cmake/FindPAPI.cmake Outdated Show resolved Hide resolved
cmake/FindPAPI.cmake Outdated Show resolved Hide resolved
cmake/FindPAPI.cmake Outdated Show resolved Hide resolved
cmake/FindPAPI.cmake Outdated Show resolved Hide resolved
profiling/chrome-tracing/CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
@mzuzek mzuzek force-pushed the cmake-build-system branch 3 times, most recently from 5b7e037 to 713ad68 Compare November 12, 2021 18:10
@mzuzek mzuzek force-pushed the cmake-build-system branch 3 times, most recently from 4c285eb to baa6bd7 Compare December 2, 2021 11:07
@mzuzek mzuzek mentioned this pull request Dec 2, 2021
3 tasks
@mzuzek
Copy link
Author

mzuzek commented Feb 23, 2022

Thank you @jrmadsen for a thorough review and great comments!

@mzuzek
Copy link
Author

mzuzek commented Feb 23, 2022

@crtrott @jrmadsen @daboehme @khuck @DavidPoliakoff @fnrizzi

At this point I was able to draft a CMake build system for KokkosTools with:

  • shared libraries built for most native tools and connectors;
  • single library interface that connects all native tools, Caliper and some TPL connectors;
  • Kokkos settings acquired from existing installation or Kokkos included in parent project;
  • sample app that links tools and TPLs with new single library interface (see example folder) + CMake tests running this demo with all implemented tools;
  • Windows/MSVC build tested with VTune and Caliper;

You'll find more details in the PR description (just cleaned it up). I hope this shows overall idea about how things are connected, configured and built: any suggestions and ideas you may have will be much appreciated. My default plan is to continue with connecting the remaining tools same way.

@crtrott
Copy link
Member

crtrott commented Mar 3, 2022

FYI: I think this looks really good. I think priority should be the NVIDIA connector tool and the CMake export.

CMakeLists.txt Outdated
Comment on lines 6 to 11
cmake_policy(SET CMP0054 NEW) # simplify if()
cmake_policy(SET CMP0057 NEW) # support IN_LIST in if()
Copy link
Member

Choose a reason for hiding this comment

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

These two are pointless if we require cmake 3.16

Copy link
Contributor

@vlkale vlkale Dec 8, 2022

Choose a reason for hiding this comment

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

Removed in PR.

CMakeLists.txt Outdated
Comment on lines 25 to 29
# Common settings
option(BUILD_SHARED_LIBS "Build shared libraries" ON)
if(WIN32)
set(BUILD_SHARED_LIBS OFF) # We need to add __declspec(dllexport/dllimport) for Windows DLLs
endif()
Copy link
Member

Choose a reason for hiding this comment

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

What is the intent here? BUILD_SHARED_LIBS is a global flag recognized by CMake. It does not need to be an option. Was that an attempt to change the default value to ON.
Also what is is the deal with Windows? What would be the point to build static?

Copy link
Member

Choose a reason for hiding this comment

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

Regarding the option: yeah I think the idea was to have the default be ON.
And on Windows you can still link a static tools library into your app, and use the API to set callbacks. We may wanna actually set the KokkosTools_ENABLE_SINGLE default to ON for windows.

Copy link
Contributor

Choose a reason for hiding this comment

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

If you want to get semi-lazy for windows and avoid all the import/export mess, just set CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS to ON.

Copy link
Contributor

Choose a reason for hiding this comment

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

Regarding the option: yeah I think the idea was to have the default be ON. And on Windows you can still link a static tools library into your app, and use the API to set callbacks. We may wanna actually set the KokkosTools_ENABLE_SINGLE default to ON for windows.

Yes, that makes sense. I will set KokkosTools_ENABLE_SINGLE (or KokkosTools_ENABLE_MONOLITHIC?) to ON.

endif()

# Tools settings
option(KokkosTools_ENABLE_SINGLE "Build single library interfacing all profilers and dispatching at runtime" OFF)
Copy link
Member

Choose a reason for hiding this comment

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

Did we discuss that name "single"? I suppose we can revisit later.

Copy link
Member

Choose a reason for hiding this comment

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

not sure we discussed but yeah I agree we can revisit. MONOLITHIC might be another option? Or do it the other way around and name the option KokkosTools_ENABLE_SEPARATE_LIBS or so, which by default is ON?

Copy link
Contributor

Choose a reason for hiding this comment

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

Using KokkosTools_ENABLE_MONOLITHIC makes most sense to me, JM2C.

mark_as_advanced(KokkosTools_REUSE_KOKKOS_COMPILER)

# Fetch Kokkos options:
acquire_kokkos_config()
Copy link
Member

Choose a reason for hiding this comment

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

When is this useful/desirable?

Copy link
Member

Choose a reason for hiding this comment

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

Is this used for stuff like the connector tools to find the same CUDA library? Also there is some tools which have their own "ENABLE_CUDA" etc. e.g. the nvprof thing enabling is based on Kokkos_ENABLE_CUDA, and APEX use of CUPTI is based on the Kokkos option.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think so, I will dig in.

Copy link
Contributor

Choose a reason for hiding this comment

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

The acquire_kokkos_config() is used to show/print the kokkos configuration to the user, and to potentially set underlying (e.g.,CUPTI) tools options (e.g., ENABLE_CUDA).

Copy link
Contributor

Choose a reason for hiding this comment

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

I can't find any connector tools right now making use of this from a quick look. I am leaving this line in for now.

CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
vlkale and others added 27 commits December 5, 2022 08:43
Apple error and using Apple CMAKE variable
Apple Error message and using Apple CMAKE variable
More fixes for cleaner builds based on feedback from other Kokkos developers specifically @dalg24
Fixes in CMakeLists.txt based on feedback
Error out if Caliper or Apex not found , fix USE_MPI to KokkosTools_HAS_MPI  (followingthe status message  at the end of file printing value of USE_MPI and the naming convention established.). 

Notes: 
* Exit out of the build if Caliper and Apex are not found. 
* If MPI isn't found, the build just continues without MPI enabled.
…++11 -g -I$(VTUNE_HOME)/include LDFLAGS=-L$(VTUNE_HOME) directory
…kefiles

putting back in  makefile as fallback for CMakelists
@vlkale vlkale closed this Mar 9, 2023
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.

NGA FY22: improve build system
7 participants