[jdcampbe]

Summary

On Windows, miopen::GetSystemDbPath() returns an empty path for any BUILD_DEV=Off build, so
every packaged find-db/perf-db filename resolves against the process's current working directory.
An installed MIOpen therefore loads its system databases only when the application happens to be
started from the install directory, and silently falls back to a full solver search otherwise.
This gives Windows the same install-relative resolution Linux already has, by locating the
directory of the loaded MIOpen.dll.

JIRA ID : ALMIOPEN-1195

Risk Assessment

Risk 3. The change is Windows-only, host-side path resolution — no kernel, dispatch, or
support-surface change. Its blast radius is nonetheless every Windows user, because the intended
effect is that shipped find/perf databases now actually load, which changes solver selection from
a search result to the tuned database entry. Those entries come from the validated databases MIOpen
already ships, so this is the designed behaviour rather than a new heuristic. MIOPEN_SYSTEM_DB_PATH
keeps precedence, BUILD_DEV still reads from the build tree, Linux is untouched, and if the module
lookup ever fails the previous behaviour is retained.

One deliberate behaviour change worth reviewer attention: anything relying on the accidental
working-directory lookup (placing databases beside an executable and launching from there) must now
set MIOPEN_SYSTEM_DB_PATH=.. The existing comment shows working-directory resolution was a
fallback, not a design goal, but it is user-visible.

ASIC Coverage

Architecture-independent: the diff touches only host-side path resolution and an environment
registry entry, with no kernel, dispatch, default-selection, or support-surface change. Standard PR
CI is sufficient; no multi-arch sweep is warranted.

Verified end-to-end on Windows on a gfx1151 GPU, against the gfx1151 system databases added by
#10050. The lane that exercises this for real is the Windows gfx1151 db_sync test
(Smoke/CPU_DBSync_NONE.StaticFDBSync), which only has gfx1151 databases to find once #10050 lands.

Testing Summary

• Unit: three new cases in the existing db_paths GTest covering environment-variable precedence,
  the default being absolute rather than working-directory relative, and the Windows default
  following MIOpen.dll.
• Regression guard: the fix was reverted and the tests re-run, to confirm they actually fail
  without it.
• End-to-end: driver configurations decoded from real entries of the shipped system find-db, run
  from an unrelated working directory with no MIOpen environment variables set and an isolated user
  database, confirming the solution MIOpen selects is the one recorded in the system database rather
  than the result of a fresh search.
• Repo gate: pre-commit (clang-format, MIOpen GTest naming) over all changed files.
• Review follow-up: rebuilt MIOpen and the CK grouped-conv plugin on Windows/gfx1151 with the
  bounded loop (MSVC 14.44 STL, ROCm wheel clang, BUILD_TESTING=ON,
  MIOPEN_USE_COMPOSABLEKERNEL=ON), re-ran the db_paths GTest, and re-ran the driver from an
  unrelated working directory to confirm both copies of the loop still resolve the module
  directory at runtime. Loop termination itself was additionally exercised standalone against
  stubs, since a misbehaving GetModuleFileNameW cannot be produced in-process.

Testing Checklist

• MIOpen db-path unit tests - build/bin/test_db_paths.exe - Status: Passed (15/15; 3 new)
• Regression guard - reverted the fix, rebuilt, re-ran - Status: Passed (SystemDbPath_NoEnvVar_IsAbsolute fails without the fix with path '' must be absolute; SystemDbPath_NoEnvVar_FollowsMIOpenModule fails with an empty path instead of the module directory)
• End-to-end system-DB lookup on Windows, gfx1151 - MIOpenDriver conv|convfp16|convbfp16 ... -V 1 over 18 configurations taken from the shipped find-db (fp32/fp16/bf16 x forward/backward-data/backward-weights) - Status: Passed (18/18 located the database and used its recorded solution; 0/18 before the fix, which reported Database directory does not exist)
• Pre-commit - pre-commit run --files projects/miopen/src/db_path.cpp.in projects/miopen/src/env_debug.cpp projects/miopen/test/gtest/db_paths.cpp - Status: Passed
• Rebuild with the bounded loop - ninja MIOpen test_db_paths MIOpenDriver (Windows, gfx1151, CK on) - Status: Passed (both db_path.cpp.obj and solver/ck_impl_lib_loader.cpp.obj recompiled, no compiler warnings)
• MIOpen db-path unit tests after the review fix - build-dbtest/bin/test_db_paths.exe - Status: Passed (15/15, including the three new cases)
• Runtime module resolution after the review fix - MIOPEN_LOG_LEVEL=6 MIOpenDriver convfp16 -n 4 -c 32 -H 28 -W 28 -k 64 -y 3 -x 3 -p 1 -q 1 -g 4 -I NHWC -f NHWC -O NHWC -F 1 -V 1 -i 1, launched from an unrelated directory - Status: Passed ([GetLibPath] Lib Path: "...\build-dbtest\bin", Loading Composable Kernel dynamic library: ...\build-dbtest\bin\MIOpenCKGroupedConv_gfx1151.dll, Forward Convolution Verifies OK)
• Bounded module-path loop, stub-driven - standalone MSVC harness over the final loop body - Status: Passed (real API resolves in 1 iteration; always-"too small" stub terminates at the 32768-character cap after 8 iterations and returns the previous empty-path fallback instead of looping; MAX_PATH+10 stub grows once and resolves)
• Pre-commit (review follow-up) - pre-commit run --files projects/miopen/src/db_path.cpp.in projects/miopen/src/solver/ck_impl_lib_loader.cpp - Status: Passed
• PR CI - GitHub PR checks - Status: Pending
• Windows gfx1151 Smoke/CPU_DBSync_NONE.StaticFDBSync - exercises the shipped databases once feat(miopen): add validated gfx1151 and gfx1200 Navi system DBs #10050 provides gfx1151 databases - Status: Pending

Technical Changes

• src/db_path.cpp.in: implement GetLibPath() for Windows via GetModuleHandleExW /
  GetModuleFileNameW on the module owning miopenCreate, mirroring GetOwningModuleDirectory()
  in src/solver/ck_impl_lib_loader.cpp rather than introducing a second mechanism.
• src/db_path.cpp.in: GetSystemDbPath() now returns that module directory on Windows for
  non-BUILD_DEV builds. DATABASE_INSTALL_DIR is bin on Windows (CMakeLists.txt:555-557), so
  the databases are installed next to MIOpen.dll. Restructured to an early return so the
  environment override, BUILD_DEV, Windows, and Linux branches read independently.
• src/env_debug.cpp: register MIOPEN_SYSTEM_DB_PATH in the debug environment registry, matching
  the existing MIOPEN_USER_DB_PATH / MIOPEN_CUSTOM_CACHE_DIR entries, so tests can set it.
• test/gtest/db_paths.cpp: three cases added to the existing CPU_DbPaths_NONE fixture. The
  Windows case resolves the module directory independently inside the test, so it validates the
  contract rather than re-running the implementation, and skips under MIOPEN_BUILD_DEV.
• src/db_path.cpp.in, src/solver/ck_impl_lib_loader.cpp (review follow-up): cap the
  GetModuleFileNameW retry buffer at 32768 wide characters — the Windows path ceiling — instead
  of doubling without bound, warn, and fall back to the existing empty-path behaviour. Applied to
  both copies of the pattern, per review. A ternary is used rather than std::min because both
  translation units include windows.h without NOMINMAX, whose min() macro breaks the std::
  call.

Related

• [MIOpen] Windows: GetSystemDbPath() is empty for BUILD_DEV=Off builds, packaged system DBs are not found #10077 — reports this exact defect; its "Proposed fix" section is what this PR implements. It was
  closed as completed by ci: point MIOPEN_SYSTEM_DB_PATH at the artifact bin dir on Windows #10081, which only exports MIOPEN_SYSTEM_DB_PATH in the CI workflow and
  does not change library behaviour for installed users. Its "Impact beyond CI" section asked for
  confirmation against a real Windows install; the end-to-end testing above is that confirmation.
  Suggest reopening it, or tracking the user-facing half here.
• ci: point MIOPEN_SYSTEM_DB_PATH at the artifact bin dir on Windows #10081 — CI-only mitigation that this change makes unnecessary for the library path.
• feat(miopen): add validated gfx1151 and gfx1200 Navi system DBs #10050 — Navi gfx1151/gfx1200 system databases; the change that first made this code path execute
  on Windows, and the source of the databases used for verification here.

[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]

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

[cderb]

Low probability buffer error.
otherwise LGTM