FAQ
Is afmf-linux really AMD Fluid Motion Frames?
It is the same idea built the same way, driver-level frame generation from the colour buffer at present time using AMD’s FidelityFX Optical Flow for the motion and an interpolation pass, applied to any game. It is not AMD’s code for the interpolation and it is not affiliated with AMD.
Does it add latency?
Not noticeably, as with AFMF on Windows. The pacing holds the real frame back by half a frame time so the generated one lands in between, the same thing AMD’s implementation does. AFMF_PACING=0 removes the hold at the cost of an uneven cadence.
Does it work with Proton and DirectX games?
Yes. DXVK and vkd3d-proton present through Vulkan, which is where the layer sits.
Does it need an AMD GPU?
No. It needs a Vulkan 1.1 driver with subgroup basic, arithmetic and quad operations in compute, 32-bit image atomics and r8ui/rg16i storage images; every Mesa driver has them, and a device without them gets a log line and no generation. Tuned on RDNA4 and verified on RDNA3, both with RADV; a user reports it working on an NVIDIA GTX 1050 Ti. RDNA2 and Intel are untested.
Does it work with the game’s own frame generation (FSR 3/4 FG)?
Yes, and keep it on. The layer doubles whatever the game presents; in Cyberpunk 2077 under vkd3d-proton it only produced companions with the game’s frame generation enabled. Leave the in-game setting as you would on Windows with AFMF.
Can I use it together with lsfg-vk or OptiScaler?
No. Two frame generation layers fight over the same presents. With the lsfg-vk implicit layer installed, Vulkan presentation on our RDNA3 test system hung even with afmf-linux disabled (uninstall it or set DISABLE_LSFGVK=1), and OptiScaler, which replaces the game’s upscaler and frame generation inside the game process, does not work together with afmf-linux either.
Does it work on RDNA3?
Yes. Verified on an RX 7800 XT with the same tests and in Cyberpunk 2077, at about three times the GPU cost per frame of an RX 9070 XT (1.2 ms at 3440x1440), so the gain is smaller when the game already saturates the GPU.
Does it work with HDR?
HDR10 and scRGB swapchains are interpolated. Whether the game gets HDR at all is decided between Wine, the compositor and Mesa, not by the layer.
Why is my frame rate not exactly double?
The ceiling is twice the base the game reaches on Linux without the layer, minus GPU contention when the game already saturates the GPU. In FIFO at the display’s refresh rate there is no free image for companions.
Does it work with Gamescope?
Yes, with AFMF_GAMESCOPE=1 next to AFMF_ENABLE=1. Gamescope keeps more swapchain images in flight than a desktop compositor, so with the default 2 extra images most presents find no free image for the companion (31 percent generated in a test with gamescope 3.16 at 165 Hz); AFMF_GAMESCOPE=1 asks for 5, which gave every present one, and keeps the layer passive inside the gamescope process itself. The Steam Deck itself (RDNA2, Gamescope as the session) is untested; reports welcome.
Is it safe? It loads into every Vulkan process.
It is mapped into every Vulkan process but does nothing unless AFMF_ENABLE=1 is set. It reads only AFMF_* variables, writes files only when AFMF_DUMP_DIR is set, opens no sockets and spawns nothing. See SECURITY.md.
Which games and GPUs has it been tried with?
The tested hardware and games page lists every case, ours and users’, with the result. Reports from other games, GPUs and compositors are welcome as issues; the template asks for the log.
What does the log’s “no free image” mean?
The presentation engine had no image to give for the companion, so that real frame went out
alone. It is normal for a game in FIFO that already runs at the display’s refresh rate (every slot
is taken) and otherwise rare; a steady count usually means AFMF_EXTRA_IMAGES is too low for that
compositor (Gamescope: AFMF_GAMESCOPE=1).
Why 64-bit only?
The layer casts handles to pointers for logging and is built for x86_64. A 32-bit build for 32-bit DXVK titles is possible but not provided.