Problem
has_unified_memory() in src/cpp/include/lemon/system_info.h hardcodes only Strix-family gfx_target_version values:
- 1102xx (Strix Point)
- 1105xx (Strix Halo)
This will miss future AMD APUs and existing non-Strix APUs with unified memory. We have a 2400G APU (Stoney Ridge, gfx v8) that should be detected. When next-gen Strix APUs land, they may use different sub-versions.
Proposed Solution
Replace the hardcoded magic numbers with a future-proof detection strategy:
Option A: Maintainable allowlist table
static const uint16_t UNIFIED_MEMORY_APUS[] = { 1102, 1105, /* add future here */ };
// family-based match -- handles all sub-versions automatically
return std::any_of(..., [](auto v){ return gfx / 10000 == v; });Option B: Family + sub matching with gap detection
APUs tend to have sub < 10 in the second two digits of gfx_target_version (desktop RDNA GPUs use higher sub numbers). A heuristic like:
auto family = gfx / 10000;
auto sub = (gfx % 10000) / 100;
return family == 11 && sub >= 2 && sub <= 9; // Strix APUs (sub 02-09 range)
This catches current APUs AND leaves room for future ones in the same family without a code change. However, this heuristic needs validation on the 2400G and any other APU we have access to.
Option C: Hybrid -- allowlist + heuristic fallback
Start with an explicit allowlist (safest) and add a heuristic guard that warns in logs if a likely-APU gfx version is encountered but not in the allowlist. This catches both "we forgot this one" and helps future contributors add new values.
Decision needed
After testing on the 2400G, we need to decide which option to implement. I lean toward Option C -- it gives us immediate safety (no false positives from heuristic alone) while surfacing gaps as they appear in production logs.
Problem
has_unified_memory()insrc/cpp/include/lemon/system_info.hhardcodes only Strix-familygfx_target_versionvalues:This will miss future AMD APUs and existing non-Strix APUs with unified memory. We have a 2400G APU (Stoney Ridge, gfx v8) that should be detected. When next-gen Strix APUs land, they may use different sub-versions.
Proposed Solution
Replace the hardcoded magic numbers with a future-proof detection strategy:
Option A: Maintainable allowlist table
Option B: Family + sub matching with gap detection
APUs tend to have
sub < 10in the second two digits of gfx_target_version (desktop RDNA GPUs use higher sub numbers). A heuristic like:This catches current APUs AND leaves room for future ones in the same family without a code change. However, this heuristic needs validation on the 2400G and any other APU we have access to.
Option C: Hybrid -- allowlist + heuristic fallback
Start with an explicit allowlist (safest) and add a heuristic guard that warns in logs if a likely-APU gfx version is encountered but not in the allowlist. This catches both "we forgot this one" and helps future contributors add new values.
Decision needed
After testing on the 2400G, we need to decide which option to implement. I lean toward Option C -- it gives us immediate safety (no false positives from heuristic alone) while surfacing gaps as they appear in production logs.