floor: probe driver API and compute capability via a short-lived worker subprocess - #17
Conversation
|
Probe verified live before opening: |
There was a problem hiding this comment.
All reported issues were addressed across 5 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
There was a problem hiding this comment.
This is the design from #13, executed carefully, and I have no changes to request.
Checked at source: --probe-floor touches cuInit, cuDriverGetVersion, cuDeviceGet(0) and the two capability attributes and nothing else — no context retained, no model. The attribute ordinals (75 / 76) match cuda.h. On the module side the env pair is still checked first, so a rig can pin the decision without a working driver; the probe runs once per process; stdout is capped; and the part I cared most about holds — a failed probe never fabricates a numeric reading, and the stderr tail is surfaced on the wire as probe_stderr under observed, tested by name in cuda_floor_failure_evidence_preserves_stderr_without_fabricating_hardware.
One behaviour worth a sentence in the code rather than a change: the OnceLock caches a failure for the life of the process, including a 10-second timeout. That is the fail-closed direction and it is what I asked for, but it means a transient probe failure on a loaded host marks the lane HardwareUnavailable until restart. Acceptable today; if it ever bites, the fix is to cache only Ok and let the next load re-probe. A comment at the get_or_init saying "a failed probe is cached deliberately" would save the next reader from wondering whether it was an oversight.
Merging after the same rented-4090 pass I ran for #15, which is cheap and turns the gate's "GPU execution requires a GPU runner" line into a measured --probe-floor JSON from real hardware.
|
All three review findings addressed in ce87e1b:
|
There was a problem hiding this comment.
ce87e1b is a good commit and it caught something I missed: the real-worker test on the previous head looked for the binary at a wrong relative path with a hard-coded .exe, invoked it without --probe-floor, and returned early when it was not found — so it passed on every platform by testing nothing. #[ignore] plus an existence assertion plus the env override is the honest shape. The deadline-bounded pipe reads are a real fix too: a flat 100 ms after exit could turn a slow reader thread into a spurious HardwareUnavailable.
One thing to drop before merge: the commit's Cargo.lock hunk. It rolls our sibling pins back (subc-core 0.17.45 → 0.17.39, subc-control 0.11.3 → 0.11.2, and removes two git-sourced rows), because your checkout carries different sibling commits than the ones recorded in siblings.lock. Merged as-is it would undo a lock wave that landed yesterday. Please restore Cargo.lock to origin/master's bytes in this branch and leave it there; the only legitimate lock change in this PR is dropping serde from synapse-engine-cuda's dependency list, and I will reconcile that row at merge with scripts/refresh-siblings-lock.sh, which regenerates the lock against the pinned sibling commits. That script is the only tool that can produce a lock consistent with siblings.lock from outside this machine, so external PRs generally should not carry lock changes at all.
Everything else stands; merging on the hardware pass plus the lock fix.
Problem
owned_cuda_floor_decisionreadsSYNAPSE_CUDA_DRIVER_API/SYNAPSE_CUDA_COMPUTE_CAPABILITYand nothing in the tree produces them (#13). A supported machine refuses every owned-CUDA load withbackend_unavailableuntil the operator finds the variable names in source.Fix
When the environment pair is absent or unparseable, the module runs
ck-synapse-worker-cuda --probe-flooronce per process (short-lived subprocess, cached result) and evaluates the same floor predicates on the returned reading:worker_bin→SYNAPSE_OWNED_CUDA_WORKER_BIN→ sibling worker (same order as model loading).--probe-floorlinks the driver only on that path, prints exactly one JSON object, and exits non-zero with stderr context on a non-CUDA build so silence can never read as a pass.observed({"probe_stderr": ...}) and never fabricate numeric hardware readings.Unsupportedbelow-floor still carries the observedCudaMachineInfo.Verification
cargo clippy -p synapse-module --no-default-features -- -D warningsclean.cargo test -p synapse-module --no-default-features --lib -j 1 cuda_floor— 3 passed:cuda_floor_probe_retains_child_failure_and_rejects_bad_json— real subprocess: non-zero exit + stderr retained; malformed JSON rejected.cuda_floor_probe_matches_real_worker_binary_output— staged release worker returnsdriver_api 13030, CC8.9on the live RTX 4050 and clears the floor constants.cuda_floor_failure_evidence_preserves_stderr_without_fabricating_hardware— failure evidence carries stderr, never fake hardware numbers.ck-synapse-worker-cuda --probe-flooron this box:{"driver_api": 13030, "compute_capability": {"major": 8, "minor": 9}}, exit 0.Closes #13. The
windows-owned-cuda-manual-gatefrom #10 can exercise the probe against the real toolchain on dispatch.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by cubic
Owned-CUDA loads previously refused with
backend_unavailableon any machine whereSYNAPSE_CUDA_DRIVER_APIandSYNAPSE_CUDA_COMPUTE_CAPABILITYwere not both set — and nothing in the tree sets them. This adds a cached, short-lived worker probe (ck-synapse-worker-cuda --probe-floor) that reports driver API and compute capability, so the floor check works without manual environment setup.Probe behavior
worker_bin→SYNAPSE_OWNED_CUDA_WORKER_BIN→ sibling worker, matching model loading.--probe-floorprints one JSON object and exits non-zero with stderr context on non-CUDA builds, so silence can never read as a pass.observed({"probe_stderr": ...}); numeric hardware readings are never fabricated.Verification
Written for commit 3e47fa9. Summary will update on new commits.