If you don’t get the following error message [ERROR] exception during run(): CUDA out of memory ... when executing the runner, than yes, that’s likely the case.
Swapped VRAM memory is marked as non-pageable in windows (IIRC), which just means windows won’t try to further swap that memory to disk when DRAM is also running out.
So if the GPU is out of memory, and Windows is out of memory, and Windows isn’t allowed to swap overflowing memory to disk, then there’s nothing it can do but force the program to crash, else your entire system would go down.
To check if you’re running out of just VRAM or DRAM as well, just open the terminal and go to the folder where the runner.exe file resides in. Then start the starlight runner directly.
runner.exe sample.mp4 sample_starlight_out.mkv --start-frame-idx 0 --end-frame-idx 64 --ffmpeg-encoding "-c:v h264_nvenc -profile:v high -pix_fmt yuv420p -g 15 -preset p7 -tune hq -rc constqp -qp 18 -rc-lookahead 10 -spatial_aq 1 -aq-strength 15 -b:v 0 -movflags frag_keyframe+empty_moov+delay_moov+use_metadata_tags+write_colr -bf 0" --ffmpeg-preproc-filters scale=w=320:h=240,setsar=1 --upscale-factor 1 --max-gpu-mem 24
Where you just change the name of the clip to the absolute path of whatever test clip you want to test with. E.g. “c:/temp/cute-puppies”.
When I disable GPU swapping, after a minute or so of initial startup time, I get a CUDA out of memory crash like this:
[INFO] Start and End frame: 0, 83. Timebase: 1/15360
[INFO] Seeking got us to: 1, we need to go to 0
[ERROR] exception during run(): CUDA out of memory. Tried to allocate 3.52 GiB. GPU 0 has a total capacity of 23.99 GiB of which 2.00 GiB is free. Of the allocated memory 18.41 GiB is allocated by PyTorch, and 1.37 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
{"timestamp": "2025-06-01 17:53:54,989", "level": "INFO", "message": {"status": "ERROR", "frame": 0, "progress": 0}}
When I enable swapping, the first few frames are rendered correctly (and the rest as well)
{"timestamp": "2025-06-01 17:56:28,621", "level": "INFO", "message": {"status": "RUNNING", "frame": 0, "progress": 0}}
[INFO] Start and End frame: 0, 164. Timebase: 1/15360
[INFO] Seeking got us to: 1, we need to go to 0
[INFO] total number of frames written: 32, 64, 64, 165
...
In my case I don’t get a crash since I have 128 GB RAM with plenty free. But if I hadn’t I’d been in trouble as well. From what I can see the peak DRAM usage for starlight during startup seems to be around 18-20GB. But it could well be higher for an instant (32GB+), since my measurement tools weren’t accurate enough to capture these microsecond peak usages [1]
[1] A picosecond of using too much memory is just as bad as infinity of using the same amount, so the time duration for excess usage doesn’t matter if swapping isn’t possible.
Yes, Absolutely. And very well I’d estimate.
See, what Topaz has cleverly done with the Mini model is not to use their existing TVAI engine (ffmpeg plugin)
The problem (or one of the problems) with that engine was that it was built on an ancient versions of nVidia tech, so ancient it didn’t support Blackwell.
With SLM they Instead seem to be using the latest pytorch with CUDA 12.8. The last bit is key for blackwell. The recent pytorch is just an extra performance boon for us (optimizations there as well).
In short, I’d expect Blackwell to perform at peak performance, finally stomping my “old” 4090 
