Skip to content

fix: make rocProfiler-SDK temporal ordering check non-fatal by default#479

Open
mapatel-amd wants to merge 1 commit into
amd-stagingfrom
users/mapatel-amd/rocprofiler-temporal-ordering-gfx1151
Open

fix: make rocProfiler-SDK temporal ordering check non-fatal by default#479
mapatel-amd wants to merge 1 commit into
amd-stagingfrom
users/mapatel-amd/rocprofiler-temporal-ordering-gfx1151

Conversation

@mapatel-amd

@mapatel-amd mapatel-amd commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Summary

  • external_correlation_id_request aborted whenever a correlation ID appeared to retire before its operation's end timestamp.
  • GPU dispatch and CPU-side retirement timestamps are in different clock domains; on RDNA3.5 APUs (gfx1151) they skew up to ~200 µs, so a correctly-ordered retirement
    looks early and the example throws. gfx1100 (discrete) is unaffected.
  • rocprofiler itself only warns and swaps these inversions by default, failing only under ROCPROFILER_CI_STRICT_TIMESTAMPS. This mirrors that policy: always print the
    violation + count, only throw when that env var is set. The unseen/unretired invariants stay unconditional.

Evidence

Nightly CI on gfx1151:
terminate called ... what(): temporal ordering violation in correlation id retirement
Observed skews: 1524 ns, 99057 ns, 209100 ns. Preceded by rocprofiler's own hsa_amd_profiling_get_dispatch_time ... start time is after end time ... Swapping the values
warning.
https://github.com/ROCm/rocm-examples/actions/runs/28764875296

Test plan

  • Build the example
  • Run on gfx1151: exits 0, prints the tolerated warning
  • Run with ROCPROFILER_CI_STRICT_TIMESTAMPS=1: still aborts on violation

The external_correlation_id_request example threw a std::runtime_error
whenever a correlation ID appeared to retire before its operation's end
timestamp. GPU dispatch and CPU-side retirement timestamps come from
different clock domains; on RDNA3.5 APUs (gfx1151) they skew by up to
~200 us, so a correctly-ordered retirement looks early and the example
aborts. rocprofiler itself only warns and swaps such inversions by
default, failing only when ROCPROFILER_CI_STRICT_TIMESTAMPS is set.

Mirror that policy: always report the violation and count, but only throw
when ROCPROFILER_CI_STRICT_TIMESTAMPS is set. The unseen/unretired
correlation-id invariants remain unconditional. Documented in the README.

Co-Authored-By: Claude <noreply@anthropic.com>
@mapatel-amd mapatel-amd self-assigned this Jul 8, 2026
@mapatel-amd mapatel-amd marked this pull request as ready for review July 10, 2026 16:12
@mapatel-amd mapatel-amd requested review from a team as code owners July 10, 2026 16:12

@zichguan-amd zichguan-amd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

LGTM with comments

{
const char* strict_ts_env = std::getenv("ROCPROFILER_CI_STRICT_TIMESTAMPS");
const bool strict_timestamps
= (strict_ts_env != nullptr && strict_ts_env[0] != '\0' && strict_ts_env[0] != '0');

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Maybe follow the same rules here and extract to a helper in Common utils? https://github.com/ROCm/rocm-systems/blob/6901b670c3e186f9c7052d6fc9748f0286536bdc/projects/rocprofiler-sdk/source/lib/common/environment.cpp#L93-L111, otherwise we could comment that this slightly differs from upstream behaviour.

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.

2 participants