Survive torch installed without lantern - #52
Merged
Conversation
win-builder R-devel failed 0.2.2 with two errors, both
"Lantern is not loaded":
* the auto-detect branch of the auto_devices() example
* test_resident.R
Root cause is one line in .detect_vram(). When nvidia-smi is absent it
falls back to torch::cuda_is_available(), which ERRORS rather than
returning FALSE when torch is installed without its lantern binaries.
That is exactly the state win-builder and CRAN are in, and exactly the
branch they land in, since those machines have no nvidia-smi either.
is_blackwell_gpu() has guarded this since it was written, and the
comment there says why; .detect_vram() never did. It now probes through
tryCatch() the same way, which fixes auto_devices(), sdxl_memory_profile()
and recommend() together, since all three route through it.
test_resident.R built real nn_modules at top level with no lantern
guard. The torch-dependent sections (component discovery, the dtype
table, the CUDA round trip) now sit behind one, and the pure-R sections
-- state machine, transition guards, status, print, unload -- still run
on CRAN, where they are the parts that can run.
Why the local Windows check missed it: windows-hr has lantern installed
on both R 4.6.0 and R-devel, so cuda_is_available() returns FALSE there
cleanly and the fallback behaved. cran-comments.md claimed that box ran
"without its lantern backend", which was simply untrue and is corrected
here. The box is not a proxy for CRAN on this axis.
It is reproducible locally, which is the durable fix:
TORCH_HOME=$(mktemp -d) Rscript --vanilla -e \
'library(diffuseR); library(tinytest); run_test_dir("inst/tinytest")'
An empty TORCH_HOME makes torch_is_installed() FALSE and
cuda_is_available() throw, matching win-builder. Under it the five
previously-failing examples pass and 271 assertions run green, the rest
skipping as intended.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
win-builder R-devel failed 0.2.2 with two errors, both "Lantern is not
loaded": the auto-detect branch of the
auto_devices()example, andtest_resident.R.One line caused both
.detect_vram()falls back totorch::cuda_is_available()when nvidia-smiis absent — and that call errors rather than returning FALSE when torch
is installed without its lantern binaries. That is exactly the state
win-builder and CRAN are in, and exactly the branch they land in, since
those machines have no nvidia-smi either.
is_blackwell_gpu()has guarded this since it was written, and its commentsays why.
.detect_vram()never did. It now probes throughtryCatch()thesame way, which fixes
auto_devices(),sdxl_memory_profile()andrecommend()together, since all three route through it.test_resident.Rbuilt realnn_modules at top level with no lantern guard.The torch-dependent sections (component discovery, dtype table, CUDA round
trip) now sit behind one; the pure-R sections — state machine, transition
guards, status, print, unload — still run on CRAN, where they are the parts
that can run.
Why the local Windows check passed
torch_is_installed()cuda_is_available()FALSEcleanlywindows-hr has lantern installed on both R 4.6.0 and R-devel, so the
fallback behaved.
cran-comments.mdclaimed that machine ran "without itslantern backend" — untrue, and corrected here. It is not a proxy for CRAN on
this axis.
Reproducible locally now, which is the durable fix
An empty
TORCH_HOMEmakestorch_is_installed()FALSE andcuda_is_available()throw, matching win-builder exactly. Under it the fivepreviously-failing examples pass and 271 assertions run green, the rest
skipping as intended.