[amd-bartgips]

JIRA ID : ALMIOPEN-2275

Motivation

MIOpenDriver verification fails for 3D INT8 forward convolutions in both NCDHW and NDHWC
layouts (SILOTIGER-709 / ALMIOPEN-2275). The fast solver
(ConvHipImplicitGemm3DGroupFwdXdlops) runs successfully, but the naive reference
kernel — used for output verification — aborts with a HIP symbol error:

MIOpen Error: named symbol not found
Failed to get function: naive_conv_ab_nonpacked_fwd_ndhwc_int8_t_int32_t_int8_t_0
reference kernel fail to run ConvDirectNaiveConvFwd

The same failure occurs for the NCDHW variant
(naive_conv_ab_nonpacked_fwd_ncdhw_int8_t_int32_t_int8_t_0).

Technical Details

Root cause. The JIT-compiled reference kernel (src/kernels/gpu_reference_kernel/naive_conv.cpp)
instantiates typed kernel variants via the DEFINE_3D_NAIVE_CONV_KERNEL macro. The
int8_t-output variant (…, int8_t, int32_t, int8_t, 0) was present for 2D
(nchw/nhwc) but had never been added for 3D (ncdhw/ndhwc), even though the
int32_t- and float-output 3D variants already existed and the underlying template
logic for 3D INT8 is correct.

Fix. Two macro instantiation lines added; no logic change:

DEFINE_3D_NAIVE_CONV_KERNEL(fwd, ncdhw, int8_t, int32_t, int8_t, 0)
DEFINE_3D_NAIVE_CONV_KERNEL(fwd, ndhwc, int8_t, int32_t, int8_t, 0)

Regression test (test/gtest/test_naive_conv_3d_int8_fwd.cpp). The test runs
ConvDirectNaiveConvFwd (the naive solver itself) on two 3D INT8 cases — one NCDHW
(default layout) and one explicit NDHWC via TensorDescriptorParams{miopenTensorNDHWC}.
Both use type_y=miopenInt8 (the previously missing Tout=int8_t symbol path), and
UseCpuRef() so the CPU provides the reference values while the GPU naive kernel is the
solution-under-test. Channel count is kept small (C=16) to satisfy the test data
generator's num_add < int8_max=127 overflow guard for int8 accumulation.

Test Plan

Build with the existing projects/miopen/build config
(MIOPEN_BACKEND=HIP, GPU_TARGETS=gfx942;gfx950, MIOPEN_TEST_DISCRETE=ON):

# Re-run cmake to pick up new glob entry, then build
cmake -DMIOPEN_TEST_DISCRETE=ON .
ninja test_test_naive_conv_3d_int8_fwd \
      test_unit_conv_solver_ConvDirectNaiveConvFwd \
      test_unit_conv_solver_ConvDirectNaiveConvBwd \
      test_unit_conv_solver_ConvDirectNaiveConvWrw \
      test_unit_conv_solver_GemmFwd1x1_0_1_int8

# Run regression test (both NCDHW and NDHWC 3D INT8 int8_t-output cases)
./bin/test_test_naive_conv_3d_int8_fwd

# Run broader naive/int8 smoke suite for regression check
./bin/test_unit_conv_solver_ConvDirectNaiveConvFwd --gtest_filter="Smoke*"
./bin/test_unit_conv_solver_ConvDirectNaiveConvBwd --gtest_filter="Smoke*"
./bin/test_unit_conv_solver_ConvDirectNaiveConvWrw --gtest_filter="Smoke*"
./bin/test_unit_conv_solver_GemmFwd1x1_0_1_int8   --gtest_filter="Smoke*"

Test Result

All tests run on GPU MI300X (gfx942):

Test binary	Filter	Result
test_test_naive_conv_3d_int8_fwd	all	2/2 PASSED (NCDHW 13.6s, NDHWC 13ms)
test_unit_conv_solver_ConvDirectNaiveConvFwd	Smoke*	5/5 PASSED
test_unit_conv_solver_ConvDirectNaiveConvBwd	Smoke*	4/4 PASSED
test_unit_conv_solver_ConvDirectNaiveConvWrw	Smoke*	4/4 PASSED
test_unit_conv_solver_GemmFwd1x1_0_1_int8	Smoke*	2/2 PASSED

pre-commit (scoped to the two changed files, matching CI's --from-ref/--to-ref
behavior): all hooks pass (trailing-whitespace, end-of-file-fixer, clang-format v18.1.4,
gtest-format-miopen).

Risk Assessment

Risk level: Low

• Change scope: two additive DEFINE_3D_NAIVE_CONV_KERNEL macro calls instantiating
  a template that is already used and proven for other 3D INT8 output variants. No
  changes to kernel logic, solvers, dispatch, APIs, or ABI.
• Impact: only the 3D INT8 fwd naive reference/verification path, which was
  previously broken (crashes → works). All other paths are untouched.
• Existing variants: the 2D nchw/nhwc int8_t-output variants and the 3D
  int32_t/float-output variants continue to pass their existing smoke tests.
• Test coverage: new isolated regression test added; CI will catch any future
  regression on this symbol.

Checklist

• I have added automated tests relevant to the introduced functionality
• I have sufficient test coverage for the changes, and code coverage hasn't decreased as a result of my PR
• I have ran the tests, and they are all passing locally
• I have added relevant documentation for the changes
• I have removed the stale documentation which is no longer relevant after this pull request
• I have ran make format & make check_format to ensure the changes have been formatted

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	—
🔎 pre-commit	✅ Pass	—
🚫 Draft PR	🔜 To Be Enabled	—
🚩 Feature Flag	🔜 To Be Enabled	—
📊 Code Coverage	🔜 To Be Enabled	—
🤖 therock-pr-bot	✅ Pass	—

🎉 All checks passed! This PR is ready for review.

📖 Need help? See the Policy FAQ for details on every check and how to fix failures.

🙋 Wish to Override Policy?

[therock-pr-bot]

Pre-commit check failed

⛔ pre-commit failed

Please run locally:

• python -m pip install pre-commit
• pre-commit install
• pre-commit run --all-files --show-diff-on-failure

This repo uses .pre-commit-config.yaml.

[therock-pr-bot]

🎉 All checks passed! This PR is ready for review.

[amd-bartgips]

CI fails on the Dbsync test on GemmFwdRest solver checks
This is what Claude can tell me about this (i.e. it's unrelated to this PR, so it's something wrong in the develop branch)

Dbsync gfx942 failure is pre-existing gfx942 find-db drift, unrelated to this PR

The failing Dbsync gfx942 stage (StaticFDBSync, db_sync.cpp:816) is not caused by this change. All failures are GEMM forward solvers (GemmFwdRest, GemmFwd1x1_0_2) on FP32/BF16 2D NCHW keys, e.g. 768-2048-1024-3x3-256-2048-1024-1-1x1-1x1-1x1-0-NCHW-FP32-F.

Root cause: GemmFwdRest::IsApplicable returns false when the recorded workspace exceeds handle.GetMaxMemoryAllocSize() (src/solver/conv/gemm.cpp:903 — GetWorkspaceSize → 0). The failing key records a ~27 GB workspace. These entries were reintroduced into src/kernels/gfx942130.HIP.fdb.txt.bz2 by #8174 (gfx942 SystemDB refresh), which is already on develop — so this drift exists on develop independently of this PR. Dbsync gfx90a passes, confirming it is gfx942-specific.

This PR only adds two 3D INT8 naive-kernel instantiations + a gtest; it cannot affect GEMM applicability. The fix belongs in a gfx942 DB re-clean (MIOPEN_DBSYNC_CLEAN=1) on develop; this branch will be rebased once that lands.

[assistant-librarian]

TheRock Submodule Bump Activity

Newest first

• 2026-08-31 — Included in TheRock via ROCm/TheRock#7750.