Upshift

Render less, see more. Upshift draws Minecraft's world at a lower internal resolution and resolves it back up with real upscalers, then adds a frame generator that does not need a vendor runtime. Everything lives inside Sodium's video settings, and everything works on the OpenGL and the Vulkan backend.

• Three upscalers that actually run: FSR 1 (AMD's EASU + RCAS), NIS (NVIDIA Image Scaling), and Upshift's own temporal accumulate.
• Frame generation without a vendor runtime: the previous world image is reprojected to the predicted camera pose and presented through the game's own present. One texture fetch per generated frame.
• Quality presets per family, using the exact fractions each vendor publishes.
• Automatic resolution driven by real render work, not by frame spacing.
• Performance panel: fps (+generated), frame, 1% low, work, CPU/GPU load, temperatures, clocks, VRAM, RAM, the resolution chain in use, a frame-time graph.
• Profiles for balanced, CPU-first, GPU-first and integrated graphics machines.
• No crashes, no driver hacks, no vendor libraries. If a device cannot run a family, the settings say why instead of hiding it.

Install

1. Minecraft 26.2, Fabric Loader 0.19.5+, Java 25+.
2. Drop the jar in .minecraft/mods.
3. Sodium is strongly recommended (the settings page lives in its video settings screen). Without Sodium the mod still runs, it just has no UI - the config file config/upshift.json is used.

Where the settings are

Options → Video Settings → Upshift Group Options Upscaling profile, automatic resolution, target frame rate Upscaler upscaler family, quality preset, internal resolution, sharpness, full EASU Behaviour automatic fallback, experimental backends, debug overlay Frame generation generator, always generate, capability report

Reading the panel

frame is the spacing between presented frames. work is how long the renderer actually spent. They differ by everything the frame was parked on - vertical sync, the frame limiter, the away-from-keyboard limiter - and both decisions the mod makes follow work: automatic resolution will not collapse because the game capped itself, and frame generation will not generate when real frames already fill the display.

What runs, and what cannot

Feature State Why FSR 1 (EASU + RCAS) works AMD's MIT reference kernels, ported to fragment passes NIS works NVIDIA's MIT shader plus its 2048-entry coefficient tables Temporal accumulate (TAAU) works jittered projection, rotation reprojection, clamped history Fast bilinear + sharpen works one pass, five taps Built-in frame generation works render-skip reprojection, OpenGL and Vulkan Automatic resolution, profiles, panel works - DLSS hardware-blocked needs NGX and tensor cores (Turing or later) DLSS / FSR / XeSS frame generation blocked needs the vendor's optical-flow runtime and swapchain ownership XeSS hardware-blocked XMX needs Arc; the DP4a path needs Pascal-class instructions FSR 2 / 3.1 / 4 blocked needs the FidelityFX runtime, which is not shipped and cannot be a fragment pass

Hardware-blocked families still appear in the list, marked with the specific reason. A list that silently hides what a machine cannot do is worse than one that says it.

Measured on a GTX 750 Ti

i5-3470, 1400x900 window, New World, render distance 8, CPU-first profile Configuration Presented fps Render work Native, no upscaler 519 0.4 ms Temporal, quality (933x600 → 1400x900) 725 0.3 ms NIS, quality (933x600 → 1400x900) 331 0.5 ms Frame generation, forced (770x495) 336 (+195 generated) 0.6 ms

Upscaling only pays when the graphics card is the limit. On a processor-bound machine the same chunks are drawn either way and the resolve is pure cost - the panel's work number and the CPU/GPU loads tell you which one you are looking at.

How it works

renderLevel HEAD
  ├─ frame generation wants this frame?
  │     yes → warp the previous image to the predicted pose, cancel the world pass,
  │           HUD on top, the game presents once                            (~0.4 ms)
  │     no  ↓
  ├─ swap the main target for the internal one (a field, no reallocation)
  …  world renders at internal resolution …
renderLevel RETURN
  ├─ swap the window target back
  ├─ temporal resolve (temporal path only)
  ├─ upscale → window target
  └─ record pose and work time
  …  HUD, screens and screenshots at window resolution …

The window target is never resized. Internal targets are cached per size and freed only at shutdown, because the frame graph and the sky renderer capture references to whichever target was current when they were built; freeing one mid-frame leaves a null texture behind.

Why a built-in temporal pass. FSR 2's value is not its nine passes, it is accumulating jittered frames into one image. This engine exposes no motion vectors, so the vendor kernel cannot be fed - but the camera's rotation is a pure homography in clip space, which reprojects history correctly for everything the camera sees, and a neighbourhood clamp catches the rest. That is the mechanism, without the runtime, on hardware from 2014.

Why frame generation keeps its cost down. The first version presented the swapchain twice: a deadlock on Vulkan, and a full present of cost everywhere else. This one replaces a rendered frame instead of adding a present: on every second frame the world pass is skipped and the previous image is warped straight into the window target, HUD on top. One present per frame, 0.2-0.6 ms per generated frame.

Compatibility

• Minecraft 26.2, Fabric. Client side only.
• OpenGL and Vulkan backends both work.
• Sodium: settings page provided through the Sodium Config API. Optional, but you want it.
• No conflict with shader packs by design (an upscaler is not a shader loader), but a shader pack that already reprojects or temporally accumulates its own history will fight the temporal path - in that case use NIS or FSR 1.