[amd-vkale]

Motivation

First week of the range replay test roadmap (source/docs/conceptual/range_replay/range_replay_test_plan.md): C1 and C2. Range replay must decline a range when a copy writes device memory inside it, because the replayed passes would run without that write. Two bugs in this area were fixed in #10864 without a regression test:

• the decline only happened while something traced memory copies;
• hsa_amd_memory_async_batch_copy bypassed it.

These are the first tests that drive an application's range into a decline on hardware.

Stacked on the test roadmap branch (users/vkale/range-replay-test-plan-with-cursor-fixes-help), which is stacked on #10864.

Technical Details

New tests/range-replay-declines/, in the style of tests/range-replay-local-context:

• Application (main.cpp). It binds its range with one kernel and writes 1 MiB of device memory from pinned host memory with a copy. A second kernel then reads both ends of the copied buffer into the result. RR_DECLINE_MODE selects the copy:

  • hip-memcpy-async (C1): hipMemcpyAsync host-to-device on the range's stream.
  • hsa-batch-copy (C2): hsa_amd_memory_async_batch_copy with one linear op, waited for on the host. The entry point is resolved with dlsym. Before the range opens, one small probe copy checks that the runtime accepts the operation, so a runtime that lacks or rejects it skips instead of failing. The case is compiled only where the HSA headers define HSA_AMD_MEMORY_COPY_OP_VERSION.

  After end(), it checks the result and every copied element, because a decline must not change what the application computes.

• Tool (client.cpp). It configures the range replay domain and nothing else, so no memory-copy tracing is active in the process. It asks for four passes. It passes only if CLOSE reports RR_DECLINE_EXPECT (MEMORY_COPY_IN_RANGE), exactly one observed dispatch, and no PASS callback.

• Copy size. HIP performs a hipMemcpyAsync of up to GPU_FORCE_BLIT_COPY_SIZE (16 KiB by default) with a copy kernel on the application's own queue. That kernel reaches the range as a dispatch, not as a copy. The tests copy 1 MiB so the copy goes through hsa_amd_memory_async_copy*.

• No GPU. The application exits with [app] SKIP and tells the tool through the environment, so the test reports skipped rather than failed.

Roadmap update (the plan is revisited the first week of each month):

• the coverage table lists the new tests;
• the unit test count is now 92;
• "what is missing" describes the small-copy gap above: such a range is replayed, not declined, and a replayed pass re-reads host memory the snapshot does not cover;
• C28 is scheduled into the 2026-12-28 buffer week, to test whichever behavior is chosen.

Issue Tracking

Related: #10864 (range replay, whose copy declines these tests guard).

Test Plan

• test-range-replay-decline-hip-memcpy-async (C1) and test-range-replay-decline-hsa-batch-copy (C2) on the mi325 CI jobs.
• Locally, with no GPU or ROCm on the build machine:
  • clang-format 11 and cmake-format are clean;
  • the tool compiles with -W -Wall -Wextra -Wshadow -Werror against the in-tree headers;
  • the application's host code compiles with the same flags against the in-tree HIP and HSA host headers, with and without the batch copy declarations;
  • a CMake harness with stand-in imported targets configures the directory and registers both tests with the intended environment, pass, fail and skip expressions;
  • a separate CTest check confirms that a run printing only [app] SKIP reports Skipped.

Test Result

CI for this PR is pending. Nothing could be run on a GPU locally. The device code was not compiled here, because the in-tree HIP headers need a newer clang than the one on the build machine.

The base, #10864 at 0844152fe6, was green for range replay on mi325: 103 range replay tests passed and 1 was skipped on ubuntu-22.04, and 100 passed with 1 skipped on TheRock gfx94X. Its red jobs were:

• rocprofv3-test-attachment-attach-once-att (TheRock): the attached app's JSON output was missing. This also fails on develop.
• thread-trace-api-triple-buffer-no-pause-test and the kernel-replay-spm sample (ubuntu-22.04): both aborted. The kernel-replay-spm sample and the -multiple-cmds triple-buffer variant have aborted on develop before. I have not seen the -no-pause variant fail on develop.
• Core sles-15.6 and Code Coverage: hit the 30-minute action limit while still configuring and building, before any test ran.
• therock-pr-bot: timed out waiting for required checks.

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/rocm-systems/blob/develop/CONTRIBUTING.md.

  

[github-actions]

This pull request has been inactive for 25 days and will be marked as stale.

If you would like to keep this PR open, please:

• Add new commits
• Add a comment explaining why it should remain open

This PR will be automatically closed in 5 days if no further activity occurs.

[github-actions]

This pull request has been automatically closed due to inactivity (30 days with no updates).

If you'd like to continue working on this, feel free to reopen the PR or create a new one.