TL;DR: Spent 3 whole days of SLP tuning: 1.06 → 2.4 fps on 1920×1080 output (2.26×, a 126% increase; +78.9% of that is from the tuning alone, the rest from cropping pillarbox). Free tuning launcher on GitHub — binary-only, Windows x64, fully reversible:
RESULTS:
Earlier in this thread I reported 1.06 fps processing 1920×1080p at 1x enhance. After countless parameter tests, I’m now getting 2.4 fps on the same videos. One clarification so I don’t oversell the tuning: I also cropped the black bars off my old 1920x1080 videos. The content is 4:3, not 16:9, so cropping removes about 25% of the pixels (1920 → 14## wide). With VAE tiling and tile overlap at the seams, the true processing reduction may differ from that. The tuning alone improved the speed by only +78.9%.
One consistent finding: for a given output resolution, the enhance factor (1x/2x/3x) barely affects speed — it’s the output resolution that drives speed.
VAE TILING FINDINGS (all at 1080p output on a 96 GB RTX PRO 6000 Blackwell / 96 GB system RAM)
- Disabling VAE tiles entirely → OOM. That’s weird at 1080p on 96 GB; in SEEDVR2 I got a big speedup from disabling tiling and never came close to running out. Has anyone else hit this?
- Tile size 1920 (whole frame in one tile) → no OOM, no speed increase, VRAM spiked.
- Tested tile sizes: 1024 (4 tiles/frame), 1080 (2), 1152 (2). Results: 1024 was faster than 1080 in some cases, and 1152 was fastest overall: [add fps for each].
This is counterintuitive - fewer, larger tiles should mean less overlap waste - so my working explanations are: (1) cuDNN picks kernels from exact tensor dimensions, strides, dtype, workspace limits, and hardware, not tile count; (2) 1024 and 1152 are both multiples of 128 (8×128, 9×128) while 1080 is not; (3) encode and decode are different operator stages with different tensor shapes, so tile size affects them differently and is nearly impossible to predict without exhaustive testing.
CAPACITY TIERS (a stab in the dark)
These are experimental starting points, not validated hardware recommendations. All of my development and testing was performed on one workstation with:
- NVIDIA RTX PRO 6000 Blackwell with 96 GB VRAM
- 96 GB system RAM
I did not directly test the presets on GPUs with 16, 24, 32, 48, or 72 GB of VRAM. Those tiers are conservative extrapolations from the memory behavior observed on my 96 GB system.
Use the launcher’s live memory estimate together with the VRAM and system RAM already consumed by Windows and background applications as a rough peak usage gauge. Aim for at least 4 GB free, 8 GB if you want to keep using the PC. For NVIDIA: cuDNN 9.24 at every tier, inspired by a suggestion from @naxci1 in the SeedVR2 community [9.25.0 is now out @naxci1; but performed 0.44% slower]. Results vary by GPU, driver, Topaz version, and workload. the launcher can restore Topaz’s native cuDNN files.
FUN FINDING: SeedVR2 fingerprints inside the SLP binaries
The Python extension .pyd files in Topaz’s SLP package contain explicit SeedVR2 and ComfyUI-SeedVR2 names, attributions, class names, and source-extraction comments. A case-insensitive string search for “SEEDVR2” and “ComfyUI” turns up numerous hits, e.g.:
- tcsrmwja1bgh.pyd: “SeedVR2 Video Upscaler - Latent Domain Temporal Chunking”
- _init_.pyd: “ComfyUI-SeedVR2_VideoUpscaler; Official SeedVR2 integration for ComfyUI”
- ub2q3f495bmv.pyd: “SeedVR2VideoUpscaler; SeedVR2 Video Upscaler Node; Execute SeedVR2 video upscaling”
There are MANY, MANY more instances. At minimum, this establishes that SeedVR2/ComfyUI-SeedVR2 identifiers remain in the installed runtime. In my opinion, the quantity and specificity of these strings strongly suggest the SLP runtime descends from, embeds, ports, or integrates SeedVR2/ComfyUI-SeedVR2 code, which would explain why SLP behaves and performs so much like SEEDVR2 and so differently from SLM and the other Starlight models.
And that’s a good thing. SEEDVR2 was the best diffusion based, generative video upscaler ever but installing and optimizing it through ComfyUI could be extremely difficult. Memory limits, VAE tiling, chunk sizes, overlap, offloading, and source-dependent behavior produced very different experiences among users. Even with my previous 32 GB RTX 5090, it took weeks of trial and error experimentation before I could run SeedVR2/ComfyUI reliably and obtain the results I wanted. Users with less VRAM or less experience could easily encounter OOM errors, poor settings, slow performance, or disappointing results. That complexity was the reason for the highly polarized sentiments towards SeedVR2 that we even saw in this forum. Some called it the Holy Grail, some called it crap because they either couldn’t get it running or it didn’t produce the polished results they expected.
Now that SEEDVR2 have been abandoned by its original developers, Topaz is effectively its spiritual successor - SLP is the “SEEDVR3” the community kept praying for, just encrypted and closed source. That’s fine for most people: SEEDVR2’s ComfyUI setup was too complicated for most users anyways, not to mention extremely resource intensive. Topaz made it work on as little as 12 GB VRAM and the quality is now clearly above SEEDVR2 in about every way, which is no small feat.
WHERE TOPAZ COULD DO BETTER
Topaz has optimized for the low end and for the uber expensive Topaz Cloud niche, leaving customers with high-end consumer/prosumer cards practically bottlenecked at speeds not much better than those with 16 GB cards. Stock SLP configuration on my 96 GB GPU maxed out at only 15.1 GB of VRAM usage. This launcher fills that gap: faster processing, less wasted energy (energy is expensive these days), and a smaller environmental footprint. That said, without the unencrypted source there’s only so much we can tune from the outside. Topaz’s engineers can optimize things end users like myself can’t even see: the VAE wrapper, tiler, and memory manager; generation phases; pipeline patching/diffing; dtypes and quantization; architecture dimensions; training/fine-tuning/distillation provenance; tile generation/blending; VAE memory limits; clip blending; supported attention backends; frame/spatial batching in the DiT; golden deterministic I/O. Tuning SLP from the outside is, at best, guesswork that requires immense trial-and-error and with restrictions that Topaz engineers would not have.
WHAT’S NEXT
Given how closely SLP tracks SEEDVR2, I already have an idea to speed up DiT and VAE that should be good for another 30–40% speed boost on top of the current gains, but probably only 24+ GB or maybe even 32+ GB VRAM GPUs can take advantage of. I have to get back to real work, so it will probably be awhile before I can find time to work on this next phase.
Update: A troll is flagging this tread so it might get deleted if it is not already censored. You can follow in this reddit link. Next version has automatic tuning and benchmarks and also a fix for SLP’s extremely long load times for some video file types.
reddit dot com/r/TopazLabs/comments/1vygtvi/comment/p70wf6z/
