volt-gui: a Vulkan control panel that sits under every driver

An implicit Vulkan layer rather than a driver control panel

The project describes itself as a Linux alternative to the AMD Adrenaline and NVIDIA Settings control panels, and the mechanism is what makes that claim credible. Settings are not applied by patching driver configuration. They are applied by volt, an implicit Vulkan layer written in Rust, which the loader picks up automatically for Vulkan 1.0 and newer applications. The stated requirement is Vulkan 1.0+, and the layer requests nothing beyond VK_KHR_swapchain, so the README argues that behaviour never splits between drivers.

The driver list is the point: RADV, ANV, NVK, AMDVLK and the NVIDIA proprietary driver all sit behind the same twenty settings. A per driver control panel cannot offer that, because a Mesa driver and a proprietary one expose different controls. The trade off is that the layer can only work with what Vulkan itself exposes, so the option lists are narrow by construction.

The repository structure matches the split. The Cargo manifest builds the crate named volt with a cdylib and rlib library, plus two binaries, volt and volt-probe, while the Python side is pinned in requirements.txt to PySide6 6.11.2 and pyinstaller 6.22.2. The graphical application is a PySide6 program packaged with pyinstaller; the thing that actually changes the game is a Rust shared library.

Twenty settings, five tabs, every value starting at default

The setting surface is small and deliberately flat. There are 20 settings across 5 tabs, and every one defaults to default, which leaves the game's own choice alone, so a profile with everything on default does nothing. Each setting is a single value: no ranges, no ordering, nothing to get backwards. That is a real constraint for anyone expecting the sliders of a commercial control panel, and it also means a profile file is easy to read and easy to reason about.

The tabs split as follows. GPU has a single setting, which device the game sees. Display has four, covering present mode, image count, compositing and clipping. Textures has seven, covering filtering, mips, anisotropy and LOD. Rendering has four, covering sample shading, alpha to coverage, alpha to one and depth clamp. Framerate has four, covering limit, cadence, method and pacing.

Present mode offers exactly four values: immediate for vsync off, mailbox as a low latency vsync, fifo as classic vsync and fifo_relaxed which tears below the refresh rate. The ones you rule out are hidden from the game's own vsync menu, and a mode defined by an extension is left where the driver put it. Swapchain images, the frames in flight count, is the anti lag dial: more lets the game run ahead of the GPU, fewer holds it closer to the display.

One operational detail catches people out. Settings are read once at game start, so pressing Apply does nothing until the game is restarted.

The probe fills the option lists from your own hardware

Most of the values in those lists are not hard coded in volt-gui. Present modes, image counts, alpha modes, GPU names, anisotropy, mip levels and LOD bias all come from a probe of the device, and a setting your hardware lacks holds only default.

The probe runs as a separate binary under the profile being edited. For each backend it can reach, it opens a one pixel window that is never mapped, creates a surface and a swapchain, creates one sampler, records what the device reported and exits. Nothing appears on screen because the window is never mapped:

volt --probe myprofile -- volt-probe

The exit code carries the diagnosis. It is 0 on success, 1 where the instance or the device could not be created, and 2 where the device lists the portability subset and the instance support that extension depends on is missing. The layer records device facts at enumeration, so the device backed cards fill either way.

Both X11 and Wayland are supported, each through a library loaded at runtime. A machine missing one reports the other, and a machine missing both leaves those settings on default, which affects present modes, image counts and alpha modes only. The probe file carries one section per backend that opened, and the card offers the union with every value naming the backends that reported it, for example mailbox (xcb, wayland) or immediate (xcb). The tag is a label only, since profiles store the value.

Where the layer backs down at runtime

Two failure modes are handled rather than hidden, and both are worth understanding before you trust a graph or a frame time.

The first is the surface refusal. Games may open gamescope or a Flatpak surface instead of a plain X11 or Wayland one, and where the game's surface refuses a value the layer handles it at runtime: the image count is clamped against the real surface, and a rejected present or alpha mode leaves the game's value in place with a warning. So a setting you configured can end up not applied, and the only signal is a warning in the output.

The second is the sampler restriction. An unnormalized, subsampled, image processing or converted sampler keeps every field its shape restricts, so a setting naming one of those fields leaves it alone and logs a line. The three sampler fields map to three settings, and linear is forced only where the sampler's own magnification filter, minification filter or mipmap mode already uses linear. Retro is nearest/nearest/nearest, bilinear is linear/linear/nearest, and trilinear is linear/linear/linear.

Then there is the setting volt cannot force at all. Physical Device picks which GPU the game sees and volt hides the rest during enumeration, but nothing in Vulkan names the device a swapchain runs on, so a game that ignores enumeration order keeps what it picked. If nothing matches the filter, the full list comes back with a warning.

Building from source with make, then launching through volt

The Quick Start in the README builds the project and runs a game through it:

git clone https://github.com/pythonlover02/volt-gui.git
cd volt-gui
make
make install-user

volt-gui          # set what you want, press Apply
volt -- ./game

The last two lines are the whole workflow: launch volt-gui, set what you want, press Apply, and start games through volt. The README states that this covers native, Steam, Wine and Proton titles. For a system wide installation the instruction is to use sudo make install instead, and the README is emphatic that you pick one and never both.

For Steam, the launcher option is:

volt -- %command%

Flatpak games need extra work, and the README has a dedicated section for it rather than treating it as part of the normal path. The Makefile is the build orchestrator, with overridable PREFIX, DESTDIR and OUT variables, a bindir and datadir, and separate 32 bit and 64 bit Vulkan layer directories for i686 and x86_64 targets. It requires GNU make 4.3 or newer, which it checks explicitly, and the Rust side declares rust-version 1.85.1 with edition 2021. The Vulkan layer manifest is VkLayer_volt.json, and the layer itself installs into the implicit_layer.d directory under the shared data path.

The build environment is worth noting if you package this yourself. Requirements are a Python interpreter for the GUI side and a Rust toolchain for the layer side, and the release script extracts the version from Cargo.toml with sed rather than keeping a second copy of it.

volt-gui and ohm-gui: one project split in two

The repository carries a note about its own history that explains the current shape of the code. volt-gui originally carried kernel settings as well, and to keep both projects easier to ship and maintain, and each with one objective, they were split. volt stays a Vulkan control panel and the kernel side now lives in ohm-gui, a separate repository by the same author.

That decision has a practical consequence for anyone evaluating the pair: a setting that changes CPU or kernel behaviour is not in this project, and a user arriving expecting the full set will find it elsewhere. The same author also states plainly that development happens in free time and that progress may be slow, with the note that the project is still maintained even if the last commit was made a while ago.

The maintenance record supports taking that at face value in the recent past. The last push was on 2026-10-08, and the release tags show v2.4.0 on 2026-09-19, v2.4.1 on 2026-09-22 and v2.4.2 on 2026-10-08, so the crate version in Cargo.toml matches the newest tag. The licence is GPL-3.0, which for a distribution that ships a shared library loaded into other people's programs is a fact to keep in mind, since the copyleft obligations of a dynamically linked layer are not the same as those of an ordinary command line tool. Whether that suits your distribution model is a question for whoever owns the licensing decision.

What the layer approach gives up against driver level tuning

There is no obvious alternative program with the same shape, so the comparison worth making is against the approaches the layer deliberately sits on top of: per driver configuration and per game launcher flags.

Driver level tuning gives you more than twenty values on a single vendor stack, including settings Vulkan has no concept of, but it is tied to one driver, it is tied to the desktop session rather than the application, and on some stacks the panel only exists for X11 sessions while the game runs under Wayland. volt takes the opposite route. It sits inside the Vulkan loader, applies the same twenty values to every supported driver, and scopes them per game by launching that game through volt. The cost is coverage: anything Vulkan does not expose is out of reach, and the option list is restricted to what the probe can query plus a small set of fixed values such as nearest and linear, which are core Vulkan with no query behind them.

The alternative to volt for a specific problem is often smaller. If the complaint is tearing, a compositor level or gamescope arrangement may address it without a Vulkan layer. If the complaint is frame pacing in one title, a per game environment variable or launcher option may be enough. What volt adds is that the same profile can be applied to a native build, a Steam title, a Wine game and a Proton title, and that the choices are validated against the hardware instead of guessed.

The remaining question is coverage of platforms. The Makefile builds both 64 bit and 32 bit layers for x86_64 and i686 targets on Linux, and the README treats Flatpak games as extra work rather than a first class case. Anyone whose library of choice lives in a Flatpak sandbox should read that section before assuming a profile will reach the game.

Editorial conclusion

volt-gui fits a Linux player who wants present mode, swapchain image count, texture filtering and frame pacing changed for one game without touching a driver control panel, and who is willing to restart the game after every Apply because settings are read once at startup. It does not fit a user who needs a different GPU selected for a game, a Wayland or X11 machine missing the matching backend library, or a Flatpak title that has not been set up separately. Verify first by running volt --probe myprofile -- volt-probe and reading the exit code, since 1 means the instance or device could not be created and 2 means the device lists the portability subset, which is the difference between a broken setting and a hardware one your card does not have.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pythonlover02/volt-gui on GitHub
4. README
5. Releases