2.0.3 Released

Small Fix:

2.0.3 is a small fix over the 2.0.2 release, changing:

• Setting descriptions are shorter. Some of them had grown into paragraphs
  sitting under a dropdown at 9pt, which nobody reads in a settings panel. The
  long explanations live in the Welcome window, where you actually go to read
  things. Frame Limit Cadence and Depth Clamp were the worst offenders.
• The probe failure dialog is three sentences instead of a wall of text.
• Small cleanup in the Options tab code, no behaviour change.

Original 2.0.2 release notes:

2.0.2 is a small fix over the 2.0.1 release, changing:

• The probe is now volt-probe, volt's own binary, built by make and
  installed next to the launcher. mesa-demos is no longer needed. It opens a one
  pixel window that is never mapped, makes a surface, a swapchain and a sampler
  so the layer sees every path a card is read from, and exits. Nothing shows up
  on screen.
• Texture Filtering is gone, replaced by three cards: Magnification Filter,
  Minification Filter and Mipmap Mode. Those are three separate sampler
  fields, so every combination is reachable now, and Mipmap Mode no longer
  overrides what Texture Filtering set. In the order mag, min, mipmap: retro is
  nearest, nearest, nearest. bilinear is linear, linear, nearest. trilinear is
  linear, linear, linear. Sharp pixel art without the distant shimmer is
  nearest, linear, linear.
• New setting, Frame Limit Cadence: which rate the limiter paces at.
  fixed is your cap and nothing else. smooth paces at the slowest of the
  last few frames, so the fast frames wait for the slow ones. dynamic does the
  same but rounds that reading down to a quarter step of your cap, so it sits on
  a set rate instead of following the load. The steps are quarter steps of the
  cap's frame time: a 60 cap steps 60, 48, 40, 34, 30, a 240 cap steps 240, 192,
  160, 137, 120. Both are the console approach, which is picking a rate the
  machine can hold and staying on it rather than letting frame time follow the
  load. A console gets there by dropping resolution, volt cannot touch
  resolution, so frame handling is the one place it fits. Neither goes faster
  than the cap you set.
• New settings, Alpha To One and Depth Clamp. Both are read from the
  device and both work like anisotropic filtering does: volt does not enable the
  feature, so where the game left it clear the setting is ignored and a line is
  logged. Depth Clamp stops weapon models getting sliced open when the camera
  backs into a wall.
• Removed Colour Depth, Colour Space and Transfer Function. They
  broke games. Every 10 bit surface format is UNORM, so forcing 8 to 10 also
  drops hardware sRGB encoding and the picture ends up washed out, and a game
  that hardcoded its format is left with image views that no longer match the
  swapchain. Transfer Function was worse, the game picks srgb or unorm to match
  what its own shaders do, so either value is wrong for the game that wanted the
  other. None of the three makes a game render wider content anyway. If you
  want HDR do it through DXVK_HDR, PROTON_ENABLE_HDR or gamescope.
• Present modes, image counts and composite alpha are answered against a
  surface, not the GPU, and there is no device side query for any of them. So
  those three cards are bounded by your display path as much as by your
  hardware, and a short list there is not a bug. volt-probe opens an X11 surface
  since every desktop has one through XWayland. It is not the only surface a
  game opens, because Wine and Proton have native Wayland drivers now, but the
  profile is written before volt knows which path the game will take, and
  probing two backends would offer values belonging to the one it did not.
  Those three settings are the only ones affected, and all three already fall
  back: image count is clamped against the real surface, and a present mode or
  alpha mode that surface turns down leaves the game's own value alone and logs
  a warning. Reading a native Wayland surface directly is planned and on my todo.
• 21 settings across 5 tabs now, up from 20.

Original 2.0.1 release notes:

2.0.1 is a small fix over the 2.0.0 release, changing:

• New setting, Frame Limit Offset: shifts the frame limit a few frames up
  or down, -10 to 10 in steps of two, no shift by default. VRR displays want
  the cap sitting just under refresh: pick 144, set the offset to -6, and you
  land on 138. volt does not read your refresh rate and never shifts a cap by
  itself, since most displays are not VRR. Thanks to @TerohsLab for the report.
• Fixed the probe not working on the release builds. PyInstaller sets its own
  library paths and those were being passed down to volt, which stopped it from
  starting. Building from source was never affected.
• Removed the automatic update check. It never worked reliably in the release
  builds and it was off by default anyway, so the option is gone from the
  Options tab.
• README: the AUR package is now mentioned, along with a note on removing a
  1.x install before installing 2.0.

Original 2.0 release notes:

2.0.0 is a full rewrite, not an update. volt is no longer a script that exports
environment variables, it is now a Vulkan implicit layer written in Rust that
rewrites the Vulkan calls a game makes.

Everything env var based is gone: the MangoHud, Gamescope, LSFG,
Proton/Wine, DXVK, VKD3D-Proton and GPU driver tabs, the OpenGL/Vulkan render
selector, and the generated volt shell script.

1.x profiles do not carry over. 1.x wrote .conf files; 2.0 uses one toml
per profile in ~/.config/volt-gui/. There is no import path, the settings
themselves no longer exist.

Remove 1.x before installing 2.0. 1.x installed into /usr/local/bin, 2.0
installs into /usr/bin, so neither uninstall target touches the other's
files. Use the next commands to remove 1.4.1:

sudo rm -f /usr/local/bin/volt /usr/local/bin/volt-gui /usr/local/bin/volt-helper
sudo rm -f /usr/share/applications/volt-gui.desktop
sudo update-desktop-database /usr/share/applications

Why the rewrite

The env var approach never held up. There is no standardization across Linux
driver stacks; a setting you can control on the NVIDIA proprietary driver often
has no equivalent on RADV, and the other way around. volt-gui ended up being a
front end for a maze of per driver variables that behaved differently depending
on what you happened to be running, even between versions of the same driver.

A Vulkan layer sits below all of that. It rewrites what the game asks Vulkan
for, so the same setting behaves the same way on RADV, ANV, NVK, AMDVLK and the
NVIDIA proprietary driver. Driver agnostic by construction.

2.0.0 Changes

• volt is now a Vulkan implicit layer (VK_LAYER_VOLT_settings), written in
  Rust, applied through the volt launcher.
• 19 settings across 5 tabs: GPU selection, display and swapchain, texture
  sampling, rendering toggles, and volt's own frame limiter.
• Vulkan 1.0 is the floor and the ceiling. The layer requests nothing beyond
  VK_KHR_swapchain, so old GPUs are covered and behaviour never splits between
  drivers.
• volt enables nothing. It reads what the game asked for at device creation
  and applies a feature-gated setting only where the game itself enabled that
  feature. It never adds an extension or sets a feature bit the game left clear. This is to avoid issues with weird driver paths, or the game itself.
• Option lists are read from your hardware. Present modes, colour depths,
  colour spaces, transfer functions, alpha modes, GPU names, mip levels and LOD
  bias all come from a probe of your own device, not from a table baked into
  volt-gui. A setting your device cannot do holds nothing but default.
• Frame limiter with three wait methods (early, late, reactive) and four
  pacing modes (sleep, sliced, precise, spin). late is the equivalent of what
  Reflex and Anti-Lag do here.
• Dual-arch in one build: make produces an x86_64 and an i686 layer served
  by a single manifest, so 32-bit games under Steam, Wine and Proton are covered.
• Rootless install, everything into ~/.local, for SteamOS,
  Bazzite, Silverblue and anything else with a read only /usr.
• Flatpak support via a runtime extension for org.freedesktop.Platform 23.08, 24.08 and 25.08.
• Profiles and presets: one toml per configuration, switchable from the GUI,
  the system tray, or the launch command. Presets run from Quality down to
  Potato Low Latency.
• Reproducible container builds (make release-container) against
  rust:1.85.1-bookworm, so the glibc floor is fixed regardless of your host.

Requirements

• Layer: Vulkan 1.0+ with VK_KHR_swapchain, Linux x86_64 (and i686 for
  32-bit games)
• Probe: volt-probe, built and installed alongside the launcher. Every
  device-backed option list is read through it. It links libxcb, which every
  desktop already has through XWayland.

Native aarch64 builds are not provided; see the README for FEX-Emu / Box64.

Builds

• Built inside rust:1.85.1-bookworm (Debian 12, glibc 2.36), so anything
  newer works and anything older will not. x86_64 only.
• The archive is a ready to install tree: unpack it, then sudo make install or make install-user installs without compiling anything.
• Flatpak extensions ship in the archive but are not installed by default: make flatpak-install-user (or sudo make flatpak-install).
• For more, read the README
  or the Welcome window the program shows on first run.

Testing wanted

This has been tested on my own machines and my friends'. That is not a lot of
hardware. If a setting behaves oddly on your driver, run the game with
VOLT_LOG=info and open an issue with the output, that log names exactly what
the layer applied and what your device turned down.

Extras

About the icon, right now it is a scaled down screenshot of the program itself. That is a placeholder. I haven't found something I actually like yet and I want something unique for it, so it stays as is until I do. And no, I am not going to AI generate one, before anyone suggests it. If you are an artist and want to contribute one, open an issue :).

If you'd like to support my work in the FOSS community, you can do so by
contributing to any of my projects or by donating. Every contribution no matter
the amount is greatly appreciated and helps keep these tools alive, maintained,
and evolving.

That's all for now, thank you for using my projects! If you can, please consider
donating, and as always, GLHF!

Release: