[JonathanLichtnerAMD]

JIRA: ALMIOPEN-1779 · Closes: rocm-libraries#2266

Summary

StaticFDBSync[gfx950] has failed on 2 stale ConvHipImplicitGemmGroupWrwXdlops perf-config entries in the gfx950 SystemDB every time it's been run — under the original frozen container CK and a fresh source-built CK alike, so these are genuinely stale entries, not a CK-version artifact:

fdb-key: 128-7-7-1x1-1888-7-7-128-0x0-1x1-1x1-0-NCHW-FP16-W
fdb-key: 240-14-14-3x3-240-14-14-16-1x1-1x1-1x1-0-NCHW-FP16-W_g240

Same class of issue PR #10043 fixed for gfx942 — but no gfx950 hardware was available here to run the usual real-hardware MIOPEN_DBSYNC_CLEAN pass.

How this was fixed (GPU-free, via the rocjitsu dbsync CI from ALMIOPEN-1779)

1. Fetched a source-CK TheRock gfx950 build artifact.
2. Ran StaticFDBSync[gfx950] under the rocjitsu KMD interposer (MIOPEN_DEVICE_ARCH=gfx950) with MIOPEN_DBSYNC_CLEAN=1 — this rewrites the find-db/perf-db files in place, removing only entries that fail applicability/perf-config validation (db_sync.cpp:847-859 → RamDb::Remove()).
3. Verified in a fresh process (CLEAN mode off, re-reading the now-modified files from disk): [PASSED] 1 test, 0 failures.
4. Downloaded the cleaned DB files and diffed them against the committed versions — confirmed exactly the 2 known-bad fdb-keys changed, and in each, only the ConvHipImplicitGemmGroupWrwXdlops entry was removed; every other solver's entry for those keys is untouched:

   -...ConvHipImplicitGemmGroupWrwXdlops:0.0575,25772032,...;ConvBinWinogradRxSf2x3:...;...
   +...ConvBinWinogradRxSf2x3g1:...;ConvBinWinogradRxSf3x2:...;ConvBinWinogradRxSf2x3:...;ConvAsmImplicitGemmGTCDynamicWrwXdlopsNHWC:...

5. Re-bzip2'd the cleaned files (round-trip verified against the pre-compression content) and replaced the committed blobs.

Changes

• projects/miopen/src/kernels/gfx950100.HIP.fdb.txt.bz2 / gfx950100.db.txt.bz2 — the 2 stale entries removed.
• test/therock/test_miopen.py — removed the "gfx950-dcgpu": {"linux": ["*DBSync*"]} exclusion and the TODO(rocm-libraries#2266) guard, so gfx950 dbsync now runs like every other family.

Test Plan

• StaticFDBSync[gfx950] passes cleanly under rocjitsu against the fixed DB (0 failures, verified in a fresh process).
• Diffed cleaned vs. committed DB content — only the 2 targeted entries changed, nothing else.
• Round-tripped the re-compressed .bz2 files against their pre-compression content (byte-identical decompress).
• TheRock CI: confirm the re-enabled *DBSync* filter passes for gfx950-dcgpu on a real run.

🤖 Generated with Claude Code

[therock-pr-bot]

✅ All Checks Passed — Ready for Review

Check	Status	Details
📝 PR Description	✅ Pass	—
⛔ Forbidden Files	✅ Pass	—
🧪 Unit Test	✅ Pass	PR does not contain code files — Unit Test auto-passed
🔎 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]

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

[JonathanLichtnerAMD]

Consolidating this into #10844 instead — that PR is what actually adds gfx950 dbsync coverage (via the rocjitsu CI), so it makes more sense to land the DB fix + re-enable there together rather than as a standalone PR. Closing this one; the same commit content will appear on #10844.