training status loading
v6.1 Pico
waiting for metrics.json
Cite this result
BibTeX
Plain text
OpenSuperSampling
OpenSuperSampling — vendor-neutral SR + frame extrapolation
OpenSuperSampling is training a unified game reconstruction pipeline for super-resolution and frame extrapolation from one temporal model.
loading status…
What's new in this arch?
Research model — not the end-user inference model.
Every run shown on this dashboard (v5, v6.1, v6.2-pico-002, …) is a research / teacher model. The backbone (HAT-Tiny) is too expensive for real-time game upscaling: measured FP16 eager forward is ~54 ms at 270×480 LR and ~1,890 ms at 1920×1080 LR on RTX 3080 Ti (idle), versus a <2 ms DLSS/FSR-class budget. The end-user shipping model will be a ≤1M-param student distilled from these teachers, in TensorRT FP8 + custom cross-vendor kernels — that student is not yet trained and is not on this dashboard. See H006 and the v6.2 architecture spec.
v6 notes: HAT-Tiny is the small HAT backbone used as the research teacher (not the shipping inference model); GS-STVSR and EWA describe the temporal canvas math; Net2Net is the expansion path; Charbonnier trains regression; Bicubic, DLSS, FSR, and XeSS are comparison anchors; PSNR and LPIPS stay as quality gauges; SDR ships first, HDR follows.
Status:
Trainer
Watcher
CF Worker
R2 origin
Current best model run
PSNR
— dB
↑ higher is better
LPIPS
—
↓ lower is better
computing from data.json…
GPU usage
loading GPU status
Training controls
Tailscale-only — opens the control surface served by homelab-desktop
If it does not load, connect this browser to the Tailscale tailnet.
Teacher / student split — what's on this dashboard vs what ships
Every run on the live dashboard is a research / teacher model. DLSS, FSR, and XeSS all follow the same pattern: train a large transformer "teacher" for quality, then distill it into a smaller CNN-class "student" for shipping. The student is the model that actually runs in a player's game at sub-2 ms per frame — and it has not been trained yet for OSS. The teachers below are what build the architectural understanding the student is then compressed against.
| Tier | Teacher (research, ON THIS DASHBOARD) | Shipping student (NOT YET TRAINED) | Target hardware | Ship latency target |
|---|---|---|---|---|
| Pico | HAT-Tiny (~3M params, transformer) Currently training: srcnn-v6.2-pico-002 |
≤0.4M-param nano-CNN TensorRT FP8 + custom kernels |
Steam Deck, integrated GPUs, mobile dGPU | <2 ms at 720p → 1080p |
| Standard | HAT-Small (~5M params, transformer) Not yet trained |
≤1M CNN TensorRT FP8 + custom kernels |
RTX 30+, RX 6700+, Arc, M2+ | <3 ms at 1080p → 1440p |
| Heavy | OSS HAT-L-derived Heavy (~17M params, transformer) Not yet trained |
≤2M CNN TensorRT FP8 + custom kernels |
RTX 4080+, RX 7900+, M4 Max | <4 ms at 1440p → 4K |
Architecture decision: transformer teacher + CNN student in every tier. Matches DLSS 4's transformer direction at the teacher level while preserving cross-vendor CNN shipping for broader hardware support. Full sprint plan + cost estimate: multi-cycle Heavy training cost memo.
Visual Progress
Recent rendered comparisons (LR · bicubic · model · GT · |error| · features) for any tracked run. Click any strip to open the lightbox compare view. Select an OSS-FX option to watch the continuous frame-extrapolation clip for that run.
Mode:
OSS-FX — continuous frame extrapolation
Real-time games can't wait for frame N+1 to render the moment between N and N+1. Interpolation (DLSS-FG style) needs both endpoints already rendered, so the in-between frame arrives one frame late — adding a full frame of input latency. Extrapolation predicts the intermediate moment from frame N alone — zero added latency, and the predicted frame can be displayed while frame N+1 is still being rendered.
OSS-FX is structurally the cheapest frame-gen path in current public knowledge: the persistent Gaussian canvas
is already warped frame-to-frame for SR; rendering it at α ∈ (0, 1) instead
of α = 1 just advances each Gaussian's position by α · motion
before the rasterizer call. No second network. No new training pipeline at inference.
What you're seeing. Continuous 3-second clip from TartanAir oldtown / Easy / P000 through the v6.2-pico-002 model at step 70,000. Native render resolution: 640×480. The model does 2× SR from 320×240 LR to 640×480 HR — that's the dataset's native ground-truth resolution. Higher output would require either a higher-resolution GT dataset (Hypersim) or a higher SR ratio (would need a different training run).
Honest disclosure on the FG frames. Per H009, the composite_head learned to weight the Gaussian canvas near zero, so scaling motion by α=0.5 in a vanilla forward pass produces frames pixel-near-identical to the SR frames (0.000225 mean abs diff vs 0.128 inter-frame motion → ratio 0.0017, no visible motion). To get something visible at this checkpoint, the FG frames in the SR + FG stream are rendered with an inference-time canvas magnification of ×50 applied at the composite_head input — equivalent to the v6.3 fusion-magnitude intervention without retraining. That bumps the extrap-vs-SR pixel diff to 0.008 (37× the unscaled baseline; ~6% of inter-frame motion). It's a hack: the model was never trained with canvas magnitudes that large, so artifacts are expected. v6.3 properly retrains with the magnitude balanced.
Inspect training lineage
Open a run to compare training, measurement, and superseded references. Run names like srcnn-v6.2-pico-002 are frozen forever — see the (i) button for the three-layer versioning convention (project semver / architecture iteration / run identifier).
loading dashboard data...
Read canonical v6 design
The canonical v6 design is the source of truth for the persistent Gaussian canvas, covariance-resampled rasterizer, cross-attention fusion path, and OSS-FX frame extrapolation plan.
Open canonical memoHypothesis > Result > Lab Notes
View all on GitHub →
Live registry of OSS research claims. Forward-looking hypotheses (H001+) with status; validated discoveries (D-series) backed by data on disk. Updated whenever a hypothesis transitions state. Source: docs/research/hypotheses/*.md + docs/research/2026-05-08-validated-discoveries-log.md.
Measured + reproducible findings on disk. Data backs every claim. Suitable for citation.
- loading…
Novel claims pending validation. Each has a test plan + acceptance gate. Status: untested, in-progress, validated, refuted.
- loading…
Status legend + protocol
untested new hypothesis, no measurement yet
in-progress measurement queued or partially complete
validated passes acceptance gate; promoted to D-series discovery
refuted failed acceptance gate; kept in registry with refutation note
partial structural property verified but not benchmarked
New finding → add as next D-number. Hypothesis transitions update both registry + this dashboard. Per OSS research-log discipline.