No description
Find a file
gaming 9e879df18e Ship gamescopereaper, without which no game can launch
Palworld would not start: the window appeared for under a second and
Steam reported the game as stopped. The compositor was fine; the log
said

    Failed to start process "gamescopereaper": No such file or directory
    Primary child shut down!

gamescope runs the game under a small watchdog and finds it with
execvp("gamescopereaper", ...), by name, through PATH. That binary is a
separate meson target, and the compositor Makefile only ever built
src/gamescope, so we have never built or shipped it. It worked on the
original machine purely because a leftover /usr/local/bin/gamescopereaper
from an old manual `ninja install` was sitting on PATH. Reinstalling that
machine removed it and every game died instantly -- not just Palworld.

Building and installing it is not quite enough on its own. The distro
gamescope package owns /usr/bin/gamescopereaper, so shipping that path
would make our package unco-installable with it, which is the exact
collision the yolkooboost-gamescope rename exists to avoid. Relying on
PATH is also what let the problem hide for so long. So
apply-reaper-name.py changes the spawned name to
yolkooboost-gamescopereaper, installed alongside the compositor under our
own prefix, and the package ships it.

Verified on the clean machine with no gamescopereaper anywhere on PATH:
Palworld launches from the packaged build alone and holds a base of 30
against a locked 60 fps output, half the frames generated.
2026-08-01 23:36:12 -04:00
dev Mon Jul 27 10:45:53 PM EDT 2026 2026-07-27 22:45:53 -04:00
docs Update the screenshot for the frame rate cap and Advanced button 2026-07-30 11:43:36 -04:00
dual-gpu-fg Mon Jul 27 10:45:53 PM EDT 2026 2026-07-27 22:45:53 -04:00
gamescope-framegen Ship gamescopereaper, without which no game can launch 2026-08-01 23:36:12 -04:00
lsfg Validate the pacing work in a real game, and conclude against it 2026-07-30 11:43:36 -04:00
packaging Ship gamescopereaper, without which no game can launch 2026-08-01 23:36:12 -04:00
scripts Fix everything a clean-machine rebuild found 2026-08-01 17:45:16 -04:00
yolkooboost Offer the frame rate cap in the UI, with a gear for the rest 2026-07-30 11:43:36 -04:00
.gitignore Add clean-room LSFG frame generation (validated in-game, pre-FSR at render res) 2026-07-30 00:20:41 -04:00
ARCHITECTURE.txt Fix everything a clean-machine rebuild found 2026-08-01 17:45:16 -04:00
LICENSE Add license (Unlicense) and refresh the launcher screenshot 2026-07-30 00:32:26 -04:00
Makefile Add a scripted dependency prefix, so the repo can build on Mint 22.x 2026-08-01 17:15:48 -04:00
README.md Fix everything a clean-machine rebuild found 2026-08-01 17:45:16 -04:00

YolkooBoost

Dual-GPU frame generation and upscaling for Linux games. Render a game at a lower resolution and framerate on one GPU, then let a second GPU (the one driving your display) upscale it with FSR and generate in-between frames with MCFI (motion-compensated frame interpolation) for a smoother picture. The goal is to help older or slower PCs put out a steady 60 fps.

It works by running games inside a patched build of gamescope, so it needs no per-game mods and no changes inside the game. A small Qt app, YolkooBoost, sets everything up for your Steam games.

The YolkooBoost interface

What you get

  • YolkooBoost (yolkooboost): a GUI that detects your GPUs, lists your installed Steam games, and turns the effect on or off per game by writing the right Steam launch options for you.
  • A patched gamescope (gamescope): the compositor that does the compositing, FSR upscaling, and frame generation on the display GPU.

Requirements

  • Linux with two GPUs, where one drives your display. The display GPU becomes the compositor; the other renders the game. (A single-GPU machine can still run it, but the point is the split.)
  • Steam (games are launched through it).
  • An X11 or Wayland desktop session.
  • For make deps: a Debian-based distribution (Debian, Ubuntu, Mint, Pop!_OS). On other distributions, install the equivalent packages by hand; make deps prints the list.

Build and install

make deps       # check for, and offer to install, the build dependencies
make            # build the patched gamescope and the launcher
sudo make install

make builds two things. The launcher is quick. The compositor is a patched gamescope built from source: the first build clones a fixed, verified release of gamescope (3.16.25, pinned by commit) with its submodules from GitHub, so it needs a network connection and takes a while.

The patched compositor installs under its own name, yolkooboost-gamescope, so it never conflicts with a gamescope your distribution may already provide. Install goes to /usr/local by default. To install elsewhere:

sudo make install PREFIX=/opt/yolkooboost

To remove everything:

sudo make uninstall

Using it

  1. Launch YolkooBoost (from your application menu, or run yolkooboost).
  2. The top shows your compositing GPU. This is fixed: it is whichever GPU drives your display, and it is where upscaling and frame generation happen. Its PCIe link is shown for reference. Pick your rendering GPU (the one the game renders on) from the dropdown.
  3. Tick a game in the list to enable YolkooBoost for it. Settings appear on the right: FSR upscaling with a render and output resolution, frame generation, and a hold-back setting. The defaults (upscaling on at 1280x720 to 1920x1080, frame generation on, hold-back 1) are a good starting point. Everything is per game.
  4. Click Apply. Steam stores launch options in a file it only rewrites when it closes, so YolkooBoost offers to close Steam, makes the changes, and offers to restart it. Your original launch options, if any, are saved and restored if you later turn a game off.
  5. Launch the game from Steam as normal.

Installed a new game while YolkooBoost is open? Click Refresh to pick it up without restarting. Refresh keeps any changes you have not applied yet.

Settings, briefly

  • Upscaling (FSR): the game renders at the render resolution and is scaled to the output resolution on the display GPU. Rendering fewer pixels is where most of the speedup comes from.
  • Render / output resolution: the game sees the render resolution as its screen size, so it renders there natively. No in-game setting needed.
  • Frame generation (MCFI): generates in-between frames on the display GPU to reach your display's refresh rate.
  • Frame generation (LSFG): optionally, the frame generator from Lossless Scaling can be used instead of MCFI. This requires a legitimate copy of Lossless Scaling installed in Steam: at game launch the compositor locates your own Lossless.dll, reads it in memory only, and runs its frame generation shaders on the display GPU. Nothing is copied, modified, or shipped. The launcher greys the option out when Lossless Scaling is not installed. Building with LSFG support needs libvkd3d-dev (checked by make deps); without it the compositor builds with MCFI only.
  • Hold-back: 1 frame is lowest latency. 2 frames is smoother if a game dips well below 30 fps, at the cost of one extra frame of input latency.
  • Limit frame rate: on by default, at 75% of your display's refresh rate (45 fps on a 60 Hz display). Frame generation interpolates between the frames the game produces, so it works best when those arrive at a steady rate, and capping the game is the biggest smoothness improvement available. For games with no frame rate limit of their own it is the only way to get one. It costs a little input delay, because a lower base rate means each frame is held slightly longer. Untick it to let the game run as fast as it can.

Advanced settings

The Advanced button opens per-game developer options. The defaults are the tested ones, so this is here to expose the knobs rather than to ask you questions.

  • Frame rate cap: turn the cap off, or set an exact value instead of the automatic 75%. Half the refresh rate is not a good choice: the game tends to get pinned at exactly that number, where 75% leaves enough slack that it settles just under the cap.
  • Interpolate before upscaling: generates frames at the game's render resolution rather than the output resolution, which roughly halves what frame generation costs. On by default; needs a compositor built with LSFG support.
  • Presenter pacing: experimental. Keeps fewer finished frames queued for the display, which cuts input delay but leaves less slack to absorb a heavy scene. In testing it saved a few milliseconds and cost occasional dropped frames, so Off is the default.
  • Show frame generation overlay: draws live counters in the corner of the game: frame rate, generated and duplicated frames, and dropped frames.

Notes

  • No conflict with system gamescope: the patched compositor installs as yolkooboost-gamescope, a separate binary, so an existing distribution gamescope is left untouched. It only needs PREFIX/bin (by default /usr/local/bin) to be on your PATH, which is the norm.

  • Pinned version: the compositor is built from gamescope 3.16.25 at a fixed commit, verified after cloning. If upstream ever moves the tag, the build stops rather than build something unverified. To try a different release, override GAMESCOPE_TAG and GAMESCOPE_COMMIT when building the compositor.

  • Older distributions: Ubuntu 24.04 and Linux Mint 22.x ship Wayland 1.22 and pixman 0.42, both older than gamescope 3.16.25 accepts, and there is no backport. make deps detects this and tells you to run:

    make prefix
    

    which builds Wayland 1.26.0 and pixman 0.46.4 into ~/src/prefix (override with PREFIX_DIR=) and records the path in ~/.config/yolkooboost/gamescope-prefix. The build and the launcher both read that file afterwards, so make and the compositor find the libraries without you exporting anything. YOLKOOBOOST_GAMESCOPE_PREFIX still overrides it at runtime if you want. On distributions with new enough libraries this step is skipped entirely.

  • Real-time frame pacing: install grants cap_sys_nice to gamescope so the frame pacer can use real-time scheduling. It still runs without it, just without that scheduling priority.

  • Frame generation at render resolution: setting YOLKOOBOOST_FG_RENDER_RES=1 in a game's launch options makes the interpolation (MCFI or LSFG) run at the render resolution before the FSR upscale instead of at output resolution after it. This roughly halves the frame generation cost and measurably smooths frame pacing, while FSR still runs once, on every presented frame, from the native render resolution. It is the recommended mode and will become the default once it has had wider testing. (The older YOLKOOBOOST_LSFG_RENDER_RES name still works. The mode needs a build with LSFG support, as it shares that machinery.)

  • Clean-room LSFG: the LSFG support was built from our own analysis and tooling (see lsfg/NOTES.md), links only the LGPL libvkd3d-shader translator, and contains no code from other LSFG projects and no shader bytecode. Your Lossless Scaling installation stays untouched.

  • Game slowdown with Lossless Scaling: sometimes a game slows to a crawl when Lossless Scaling frame generation (LSFG) is enabled. This can happen when the game is already hitting your monitor's refresh rate consistently (60 fps on a 60 Hz display), which leaves too narrow a window of time for the frame generator to do its work, especially on older GPUs which take longer to process each frame. The Limit frame rate setting exists for exactly this: it caps the game below the refresh rate (45 fps on a 60 Hz display) so the compositing GPU has the headroom to keep up. It is on by default, so if you run into this, check that it has not been turned off for that game. (Presumably your game is already running at a low frame rate, or else why are you enabling frame generation to begin with?)

License

YolkooBoost is free and unencumbered software released into the public domain. See LICENSE (the Unlicense). Third-party components keep their own licenses: gamescope is built from upstream source under its BSD-style license, the LSFG backend links the LGPL libvkd3d-shader system library, and the vendored AMD FidelityFX FSR1 headers in the development trees are MIT.

More detail

ARCHITECTURE.txt documents how the whole thing works, why it is built on gamescope rather than a Vulkan layer, and every non-obvious constraint that shaped it. dev/ holds maintainer-only scripts and is not part of the build.