[amd-bartgips]

Motivation

The gfx942 system find-DB contains entries where the naive convolution solver is listed as
fastest. For a subset of these shapes, GPU benchmarking shows a non-naive heuristic solver
is significantly faster in practice. This PR removes those entries so MIOpen can select the
correct solver at runtime.

Risk Assessment

Low risk. The change is a targeted removal of selected stale system-DB entries for gfx942 where the naive convolution solver was previously recorded as fastest but is empirically outperformed by heuristic-selected solvers. No changes to public APIs, ABI, kernel implementations, or build system are introduced; this PR only updates static DB contents. At runtime, affected cases will gracefully fall back to existing heuristic selection or full search, both of which are already well-tested execution paths. The removal criteria are conservative (≥10% measured speedup and validation against unconstrained heuristics), minimizing the risk of regressions while improving solver selection accuracy.

Technical Details

To make this somewhat feasible, we have relied on the heuristics model to select an alternative kernel to compare against (rather than run exhaustive tuning).
TLDR: we extracted all system-DB entries where naive was deemed fastest and ran benchmarks to compare the naive kernel time for these shapes to the kernel time of the kernel suggested by heuristics.

In more detail:

• Candidate extraction parsed DB lines directly (not grep-only), classifying each as
  sole-naive (naive is the only entry) or naive-fastest (naive has the lowest embedded
  kernel time on the line)
• Benchmark compared two modes on all 5,737 shapes:
  • Baseline: system DB present (naive entries active)
  • Experimental: MIOPEN_DEBUG_CONV_DIRECT=0 so heuristics must find a non-naive solver
• Removal rule: remove the entire DB line if speedup ≥ 10% AND the heuristic solver is non-naive
  • speedup = (baseline_time − experimental_time) / baseline_time × 100
• Additional validation: After identifying 249 candidate keys by the benchmark rule above, each
  was checked against the unconstrained TunaNet heuristic (no MIOPEN_DEBUG_CONV_DIRECT=0).
  13 keys were excluded because TunaNet also selects naive for those shapes — removing their
  DB entry would offer no benefit (MIOpen still picks naive, but via the slower heuristic
  path rather than the fast DB lookup)
• Whole-line removal is intentional: the remaining non-naive entries in each line are equally
  stale; removing the line lets MIOpen's find phase pick fresh with current heuristics

Test Plan

1. Parse both gfx942 DB files; classify naive-fastest keys (5,737 unique)
2. Run interleaved baseline/experimental benchmark across all 5,737 shapes
3. Apply conservative removal rule (≥10% speedup, non-naive experimental solver) → 249 candidates
4. For each candidate, run the unconstrained heuristic (no MIOPEN_DEBUG_CONV_DIRECT=0) and
   exclude any key where TunaNet would also select naive → 236 final removals
5. Apply removal, verify no removed keys remain in either DB file
6. Recompress .fdb.txt → .fdb.txt.bz2

Test Result

Full benchmark completed (5,737 shapes, gfx942 MI300X):

Metric	Value
Comparable pairs	5,710
Initial candidates (≥10% speedup, non-naive)	249
Excluded (heuristic also picks naive)	13
Final removals	236
Keep (naive genuinely fastest)	5,474
Avg speedup on removed shapes	+86.0%

The 5,474 "keep" shapes confirm naive is legitimately the fastest solver for the vast majority
of these DB entries. The 13 excluded shapes exceed the speedup threshold by benchmark but
TunaNet independently corroborates naive as best in production — their DB entries are preserved.
In the scatter plots, points above the remove-boundary line that are not marked "removed" are
these 13 excluded cases.

See a graphic overview of the benchmark results for all 5,474 shapes under consideration:

(note that there are some red dots below the removal threshold/boundary, these correspond to shapes where the TunaNet heuristics model would also select the Naive solver, hence removal would not help us here.)

Submission Checklist

• Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests.

[JonathanLichtnerAMD]

LGTM, but we need to add a "Risk Assessment" section to the PR description.

Also, this is still a "draft" PR.

[amd-bartgips]

LGTM, but we need to add a "Risk Assessment" section to the PR description.

Also, this is still a "draft" PR.

Added such a section and moved it to "ready for review" 👍

[JonathanLichtnerAMD]

LGTM. Should we add an item to the changelog for this?