Make Kokkos Tools core vendor connectors consistent with all features

[vlkale]

Background

There exists three primary Kokkos Tools core vendor Kokkos Tools connectors which provide a hook to vendor tools (NVIDIA's nvtx connector, Intel's vtune connector, and AMD rocm connector). It is possible that there may be other vendor backends in the future, but the focus for Kokkos Tools is on these three at present.

Problem

For these three vendors' associated tools, Kokkos Tools set should work towards a unified/general functionality requirements for supporting Kokkos programmers' needs of Kokkos Tools when using any of the key vendor backends. As an example, the Kokkos Tools set has nvtx/vtune connector and nvtx/vtune-focused connector, but there is no such rocm-focused connector. Functionality within each corresponding vendor-specific connector should try to be unified generalized as well (the nvtx-connector's callback for Kokkos::parallel_for() should provide the Kokkos Tools programmer the same information as the vtune-connector's callback for Kokkos::parallel_for()).

At a minimum, this means we need to have all basic support consistent across vendor connector library .cpp files. If there's a kp_begin/end_fence() in nvtx-connector, we've got to have it in roctx-connector.

Proposed Solution

• Define functionality and needs from Kokkos Tools users that all vendors tools connectors ought to provide.
• Go through each of the vendor connectors and ensure the corresponding functionality is the same.

This can span multiple github PRs for vendor tools, and is considered a general design principle in developing vendor Kokkos Tools connectors rather than a specific fix to a specific connector.

Expected Outcomes

The expected outcome is the ability to do more complete apples-to-apples comparison from a set of detailed profiles of a Kokkos program, where each profile is the result of running on a distinct vendor platforms with a corresponding Kokkos vendor backend.

(Note that we are not considering OpenMPTarget backend here to keep things simple and because there is not an OMPT Kokkos tools connector. If there was a OMPT tools connector and if it was desirable in the future: The OpenMPTarget backend would be a complementary open-source backend to each vendor-specific backend on the platform, and we would develop OMPT Kokkos tools Connector with the general set of functionality set forth here, expanding where needed.)

Notes

• Having looked into this with vendors and users, it seems like the roctx/nvtx/vtune connectors are not integrated by design from when @ DavidPoliakoff initially developed these.
• I think my understanding is that vendors support these connectors themselves, with consultation with Kokkos team.
• It's possible nvtx changes in a different way than roctx over the next several years and we need to maintain these separately. In the future, we may also have new vendor backends for Kokkos.
• A compromise: create a generic vendor connector where the Kokkos Tools user can pass in a vendor-specific push/pop functions.

[jrmadsen]

Just chiming in out of curiousity.

• Go through each of the vendor connectors and ensure the corresponding functionality is the same

What does this mean? I think the current model for these tools is somewhat broken to provide this desired outcome (i.e. having entirely separate nvtx-connector, roctx-connector, vtune-connector, etc. implementations). Seems to me what you need here is just to take the most advanced ones -- probably the NVTX ones -- and generalize it so that it substitutes in the appropriate call to whichever API was selected at build time and let the build system generate the variants:

#if defined(NVTX)
    nvtxRangePush(...); 
#elif defined(ROCTX)
    roctxRangePush(...); 
#elif defined(ITT)
    __itt_frame_begin(...);
#endif

[vlkale]

@jrmadsen I have updated the description of this Github Issue.