[xpupti] Fix CPU->GPU flow links via activity type, not an API-name allowlist

[aostrowski-hbn]

The XPU profiler marked a host record as the start of a CPU→GPU ("ac2g") flow arrow by exact-matching its API name against a hardcoded allowlist (correlateRuntimeOps_). That list did not contain urEnqueueKernelLaunchWithArgsExp — the launch API used by the 2025.3+ SYCL runtime — so kernel launches stopped emitting a flow start (ph:"s") and the host→device arrow disappeared from the trace.

Approach

Rather than add the new name to the list (which needs a new entry on every UR API rename/addition), decide the flow start from the record’s activity type: only host runtime (XPU_RUNTIME) records start a flow.

• The runtime view is already filtered to work-submitting APIs via ptiViewEnableRuntimeApiClass(PTI_API_CLASS_GPU_OPERATION_CORE).
• Driver (XPU_DRIVER) records share the runtime record’s correlation id and must not also start a flow, or the trace gets a duplicate flow start.

This removes the name allowlist entirely (robust to future UR renames) and extracts the check into a static startsFlow() for unit testing. Net −35 lines.

Note: this supersedes the original allowlist patch on this branch, following @mschilli’s suggestion to key off GPU_OPERATION_CORE / activity type instead of maintaining a name list. The XPU_DRIVER-exclusion guard is what prevents the duplicate-flow-start collision that a bare flow.start = 1 would cause.

No PTI version gate needed

ptiViewEnableRuntimeApiClass / PTI_API_CLASS_GPU_OPERATION_CORE exist since PTI 0.12.0 and are already called unconditionally on main; this change references no PTI symbol (only the Kineto ActivityType enum), so it builds on all currently-supported PTI versions (0.15–0.18 verified reasoning; 0.18 built).

Test Plan

XpuptiFlowCorrelationTest now asserts runtime records start a flow while driver and device records do not (hardware-free, in the CTest set).

Verified on Intel Data Center GPU Max (PVC), oneAPI 2026.0 / PTI 0.18:

• XpuptiFlowCorrelationTest passes; full xpupti ctest 10/10 passes.
• Rebuilt PyTorch against the patched kineto and ran a mixed workload (H2D copy, add/relu/matmul/reduction, D2H copy): every kernel and memcpy gets exactly one host→device arrow, with zero Perfetto flow errors (no flow_duplicate_id) and no PyTorch duplicate-flow-start warnings.

[aostrowski-hbn]

@ryanzhang22 please import and review

[aostrowski-hbn]

@pytorchbot label ciflow/xpu

[pytorch-bot]

The ciflow label(s) ciflow/xpu will be added, but CI won't be triggered until the workflows are approved (scroll to the bottom of this page).

Please ping one of the reviewers if you do not have access to approve and run workflows.

[pytorch-bot]

The following ciflow label(s) have been added but CI has not been triggered yet because the workflows are awaiting approval:

• ciflow/xpu

Once a maintainer approves the workflows (scroll to the bottom of the PR page), the corresponding CI jobs will be triggered automatically. Please ping one of the reviewers if you do not have access to approve and run workflows.

[gujinghui]

@ryanzhang22 @divyanshk @scotts This PR is ready for your review. Thanks.