2.3.0 Released

2.3.0 Changes

Mostly layer internals, plus one thing you might notice.

• Texture settings now land on the pipeline and shader paths too. A game using VK_EXT_descriptor_heap can bake a sampler into a shader stage instead of calling vkCreateSampler, and that was slipping past.
• A present mode list the game chains onto swapchain creation gets narrowed now. Before, a game reaching for swapchain maintenance1 kept a mode you ruled out. Narrow it to nothing and you get the whole list back with a warning.
• Everything above Vulkan 1.0 and VK_KHR_swapchain is hand rolled against the Vulkan registry now instead of taken from ash.
• Replacing a node in a pNext chain rebuilds whatever sits in front of it, the rest goes down by pointer. A node volt doesn't know leaves the setting alone with a line in the log. The chain the game built is still only read.
• Dropped vkGetPhysicalDeviceSurfacePresentModes2EXT. Needs full screen exclusive, which is Windows only. Wine answers it in winevulkan before the loader sees it, so DXVK and vkd3d games never bring it down here.

Profiles carry over, no setting changed. Off the pipeline paths this is 2.2.2.

That list undersells it though. Every setting already wrote into a create info volt owns, that part was never the problem, the problem is that a game can reach the same state somewhere else. Bake a sampler into a shader stage, chain a mode list onto swapchain creation, and volt was writing the right value into a structure the game had stopped using.

So the layer follows the state now instead of watching one call. That means declaring the structures those paths run through, and rebuilding a pNext chain properly when volt has to replace a node partway down it, which is what the middle two bullets are.

Which is also why the types are hand rolled. ash generates against whatever header it was cut for, and the paths volt needs to follow keep arriving in new and shiny extensions, so reading the registry means a path lands when it ships rather than whenever ash catches up.

Physical Device is still the exception. Nothing in Vulkan names the device a swapchain runs on, so enumeration is the only lever there is and no amount of following state changes that.

From here on that's the plan. Vulkan adds another way to reach vsync, or filtering, or whatever else, and a week later there's a volt release with that path patched so games using it still get your profile. It's a lot of work and it's not going to stop being a lot of work, but neither AMD nor Intel nor NVIDIA are going to ship a proper Adrenaline or NVIDIA Settings equivalent for Vulkan on Linux, so here we are.

I did think about an OpenGL version for a while. It isn't happening. It would be the whole project written again from scratch with more dependencies, and OpenGL isn't the standard anymore. I love it, it was my first 3D API, but after working on dxvk-sarek I don't want to go back.

Ideally as volt gets more mature some distros would start shipping it, but I'm setting my hopes way too high there :).

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 loads libxcb and
  libwayland-client at runtime and needs neither.

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.

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: