Skip to content

Conversation

@Treece-Burgess
Copy link
Contributor

Pull Request Description

Background:
In the master branch the modifier PAPI_NTV_ENUM_UMASKS is implemented throughout many of the components such as cuda, rocp_sdk, and rocm. This modifier is then used in various PAPI utilities and ctests.

Issue:
Only the CPU components have umasks. Due to this, the use/implementation of PAPI_NTV_ENUM_UMASKS for the non-cpu components is not accurate.

Resolution:
The PR introduces a new modifier called PAPI_NTV_ENUM_DEFAULT_QUALIFIERS, which serves the same purpose as PAPI_NTV_ENUM_UMASKS, but is specifically for non-cpu components that have qualifiers implemented.

Testing

The following list of files that mention PAPI_NTV_ENUM_UMASKS were not changed (reason included):

  • papi_libpfm3_events.c - CPU related
  • pe_libpfm4_events.c - CPU related
  • eventstock.c - CPU related
  • perfmon_ia64.c - CPU related
  • papi.h - Both PAPI_NTV_ENUM_UMASKS and PAPI_NTV_ENUM_DEFAULT_QUALIFIERS need to be supported
  • papi.c - Both PAPI_NTV_ENUM_UMASKS and PAPI_NTV_ENUM_DEFAULT_QUALIFIERS need to be supported
  • test_utils.c - The function enum_add_native_events.c utilizes PAPI_NTV_ENUM_UMASKS and is only called in overflow_allcounters.c where the call has the component index 0 hardcoded which corresponds to the perf_event component
  • papi_hybrid_native_avail.c - Unable to test as we do not have access to an Intel Xeon Phi as stands

Testing was done on Illyad at Oregon which has the following setup:

  • CPU: AMD EPYC 7402

  • GPUs: 1 * H100 and 1 * MI210

  • OS: RHEL 8.10

  • ROCm version: 6.1.3

  • Cuda Toolkit verison: 12.6.3

  • ./papi_native_avail and ./papi_native_avail -e: ✅

    • Note, for the -e flag I tested with CYCLES from the perf_event component and dram__bytes from the cuda component. For the cuda component, I had to add a custom implementation under PAPI_NTV_ENUM_DEFAULT_QUALIFIERS to properly test and will add this as a feature in a separate PR:
+           if (info.flags == (STAT_FLAG | DEVICE_FLAG)) {
+                info.stat = 0;
+                info.device = 0;
+                info.flags = STAT_FLAG;
+                papi_errno = evt_id_create(&info, event_code);
+                break;
+            }
  • ./papi_avail and ./papi_avail -e: ✅
    • Note, same as above for papi_native_avail -e.
  • ./papi_xml_event_info: ✅
  • ./papi_event_chooser: ✅
  • ./failed_events: ✅
    • Note, only tested with the perf_event and rocm components.
  • ./all_native_events: ✅
    • Note, only tested with the perf_event and rocm components.

Author Checklist

  • Description
    Why this PR exists. Reference all relevant information, including background, issues, test failures, etc
  • Commits
    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
  • Tests
    The PR needs to pass all the tests

@Treece-Burgess Treece-Burgess added status-ready-for-review PR is ready to be reviewed type-maintenance Update code to keep it compatible, secure, modern. labels Oct 23, 2025
@dbarry9
Copy link
Contributor

dbarry9 commented Oct 23, 2025

I am reviewing this PR.

@Treece-Burgess
Copy link
Contributor Author

For, papi_hybrid_native_avail.c I am waiting to hear back from Erik from Oregon to see if he can successfully boot the grover machine. As this machine has an Intel Xeon Phi. Therefore, I am changing the status label to wip.

@Treece-Burgess Treece-Burgess added status-work-in-progress PR is still being worked on and removed status-ready-for-review PR is ready to be reviewed labels Nov 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status-work-in-progress PR is still being worked on type-maintenance Update code to keep it compatible, secure, modern.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants