Skip to content

Keep the manual handshake working where no activity kind is required - #172

Merged
CodingInAVan merged 1 commit into
mainfrom
capture-ready-without-required-kinds
Oct 16, 2026
Merged

CodingInAVan merged 1 commit into
mainfrom
capture-ready-without-required-kinds

Conversation

@CodingInAVan

Copy link
Copy Markdown
Contributor

Why

#171 made GpuFlightInitializeInjectionAfterCuda return 1 only when every required CUPTI activity kind was enabled. PC sampling and SASS safe mode require no activity kind, because KernelLaunchHandler and MemTransferHandler return {} when kernel events are not collected. The required-activity tally therefore recorded nothing and reported activity_not_enabled, readiness failed, and the handshake returned 0 in those passes.

The Rust bootstrap and the backend's WorkbenchPythonBootstrap treat anything but 1 as fatal. Every PcSampling and SassMetrics pass of a Rust or Python lab would have aborted. This was found while preparing v1.3.0rc5, before any release.

Change

  • RequiredActivityTally gets Evaluated(), called once after the start-time enable loop, even when the required set is empty. Ready() reports a recorded failure first (failures still latch), and otherwise requires Evaluated().
  • The default initialization deadline (GPUFL_INJECT_LAUNCH_WAIT_MS) goes from 15 s to 60 s. Before Gate the first CUDA call on checked capture readiness (Linux) #171 nothing bounded gpufl::init. A slow but healthy init, such as PerfWorks setup on a large GPU, must not fail a manual handshake or be killed by the launcher watchdog. Init times will be measured in the L4 requalification.

Tests

  • New: an empty evaluated set is ready.
  • The existing tally test now also shows that a success alone is not ready before Evaluated().
  • 669/669 CPU tests pass in the CUDA 13.1 container.
  • Not run: any GPU.

🤖 Generated with Claude Code

PC sampling and SASS safe mode require no CUPTI activity kind, so the
required-activity tally recorded nothing and reported activity_not_enabled.
Readiness then failed and GpuFlightInitializeInjectionAfterCuda returned 0
in those passes, which the Rust and Python hosts treat as fatal. The tally
now becomes ready once the required set was enabled, even when the set is
empty; a recorded failure still latches and is reported first.

The default initialization deadline goes from 15 s to 60 s: before this
release nothing bounded gpufl::init, and a slow but healthy init (PerfWorks
setup on a large GPU) must not fail a manual handshake or be killed by the
launcher watchdog.
@CodingInAVan
CodingInAVan merged commit c677f05 into main Oct 16, 2026
11 checks passed
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.

1 participant