amd-vkale · Sep 10, 2026 · Sep 10, 2026 · Aug 29, 2026 · Aug 29, 2026 · Sep 10, 2026
@@ -10,6 +10,10 @@ Full documentation for ROCprofiler-SDK is available at [rocm.docs.amd.com/projec
 
 ### Resolved issues
 
+**rocpd:**
+
+  - `counters_collection` no longer sums a counter that kernel replay collects once per `--pmc` group when every pass reports the same value. Three readings of 512 report 512. Readings that differ, such as hardware instances of one counter, are still summed. The individual readings remain in `rocpd_pmc_event`.
+
 ### Known issues
 
 ### Removed

@@ -126,6 +126,8 @@ subtrees:
           title: Memory snapshot and restore
         - file: conceptual/kernel_replay/kernel_replay_performance
           title: Performance assessment
+        - file: conceptual/kernel_replay/kernel_replay_rocpd_schema
+          title: rocpd schema
         - file: conceptual/kernel_replay/kernel_replay_testing
           title: Test coverage
         - file: conceptual/kernel_replay/kernel_replay_downstream_tools

@@ -73,6 +73,7 @@ same domain for timing, PC sampling, or thread trace.
   per-dispatch snapshot cost model, the range the regression tests actually cover, the specific
   performance problems visible in the implementation, and how the cost behaves as device capacity
   outpaces host-link bandwidth across accelerator generations.
+- **[rocpd schema](kernel_replay_rocpd_schema.md)** — `counters_collection` reports a repeated counter once when every replay pass reads the same value. Readings that differ are still summed. The individual readings remain in `rocpd_pmc_event`.
 - **[Test coverage](kernel_replay_testing.md)** — what replay is tested for at each level, which
   checks need a GPU and which deliberately do not, the known gaps, and where a new test belongs.
 - **[Downstream tools](kernel_replay_downstream_tools.md)** — what it would take for

@@ -0,0 +1,26 @@
+# Kernel replay in the rocpd schema
+
+Kernel replay executes one dispatch once per counter group. Every pass reports the same
+`dispatch_id`. rocpd stores every pass's counter readings as `rocpd_pmc_event` rows on that
+dispatch's event. `counters_collection` used to `SUM` those rows, so a sanity counter repeated in
+three groups was reported three times too high.
+
+```bash
+rocprofv3 --pmc SQ_WAVES,SQ_INSTS_VALU,GRBM_COUNT \
+          --pmc SQ_WAVES,SQ_INSTS_VALU,GRBM_GUI_ACTIVE \
+          --pmc SQ_WAVES,SQ_INSTS_VALU,SQ_INSTS_SALU \
+          --replay-mode kernel --kernel-replay-beta-enabled -- ./app
+```
+
+On a kernel that launches 512 waves, each pass reads `SQ_WAVES` as 512. The view used to report
+1536. Identical readings now report that value once, so this reports 512. Readings that are not
+identical, such as hardware instances of one counter, are still summed. A counter collected once
+is unchanged. A run that never replayed is unchanged when each counter name is collected once.
+
+The three readings stay in `rocpd_pmc_event`. A query against that table still lists 512, 512, and
+512. For a deterministic counter those readings are the same number, so the view reports
+that number instead of adding the copies.
+
+`counters_collection` stays one row per dispatch per counter. That is the file most people read.
+Keeping a row per pass, with its own timestamps, would be a larger schema change, and it is not
+what this view is for. One default cannot serve both.
@@ -784,7 +784,13 @@ SELECT
     PMC_I.expression,
     PMC_I.value_type,
     PMC_I.id AS counter_id,
-    SUM(PMC_E.value) AS value,
+    -- Several rows can share a counter name. Hardware instances of one collection differ and
+    -- still add up. Kernel replay writes the same reading again for each pass, and those
+    -- copies are one measurement, so identical readings report that value once.
+    CASE
+        WHEN MIN(PMC_E.value) = MAX(PMC_E.value) THEN MIN(PMC_E.value)
+        ELSE SUM(PMC_E.value)
+    END AS value,
     K.start,
     K.end,
     PMC_I.is_constant,

@@ -117,6 +117,7 @@ add_subdirectory(environment)
 add_subdirectory(rocpd)
 add_subdirectory(rocpd-api)
 add_subdirectory(rocpd-back-compat)
+add_subdirectory(rocpd-kernel-replay-schema)
 
 # rocattach validation tests
 add_subdirectory(rocattach)

@@ -0,0 +1,34 @@
+#
+# rocpd kernel replay schema tests: drive the shipped SQL against SQLite, no GPU
+# required
+#
+cmake_minimum_required(VERSION 3.21.0 FATAL_ERROR)
+
+project(
+    rocprofiler-sdk-tests-rocpd-kernel-replay-schema
+    LANGUAGES NONE
+    VERSION 0.0.0)
+
+find_package(Python3 REQUIRED COMPONENTS Interpreter)
+
+set(rocpd-kernel-replay-schema-path "${CMAKE_BINARY_DIR}/share/rocprofiler-sdk-rocpd")
+
+# The tests build their databases from the schema SQL directly, so there is nothing to
+# profile and no application to run. The execute step only exists to provide the fixture
+# that rocprofiler_add_integration_validate_test requires.
+rocprofiler_add_integration_execute_test(
+    rocpd-kernel-replay-schema-test
+    COMMAND ${Python3_EXECUTABLE} -c "pass"
+    DEPENDS rocprofiler-sdk::rocprofv3
+    TIMEOUT 10
+    LABELS "integration-tests;rocpd;kernel-replay"
+    FIXTURES_SETUP rocpd-kernel-replay-schema)
+
+rocprofiler_add_integration_validate_test(
+    rocpd-kernel-replay-schema-test
+    TEST_PATHS validate.py
+    CONFIG pytest.ini
+    TIMEOUT 60
+    LABELS "integration-tests;rocpd;kernel-replay"
+    ENVIRONMENT "ROCPD_SCHEMA_PATH=${rocpd-kernel-replay-schema-path}"
+    FIXTURES_REQUIRED rocpd-kernel-replay-schema)
@@ -0,0 +1,5 @@
+
+[pytest]
+addopts = --durations=20 -rA -s
+testpaths = validate.py
+pythonpath = @ROCPROFILER_SDK_TESTS_BINARY_DIR@/pytest-packages