Performance

Every number below comes from the layer’s own instrumentation (AFMF_PROFILE=1: GPU timestamps per stage, host timers per present). Tested hardware: RX 9070 XT (RDNA4) and RX 7800 XT (RDNA3), Mesa 26.1.8 RADV, Fedora 44, KDE Plasma 6.7 Wayland, 3440×1440; the 9070 XT unless stated. Re-measure on your hardware; the method is the same.

What a frame costs

GPU, per generated frame, with the defaults (at this resolution: optical flow at half size, five pyramid levels), on the worst case the headless test has: a textured picture panning across the whole frame at 3440×1440, every block moving (the host paints it, so the GPU sits at low clocks; a game runs it faster):

The same scene with the optical flow at display resolution and all seven pyramid levels (AFMF_PERFORMANCE_MODE=quality AFMF_SEARCH_MODE=high) costs 674-716 µs: about a quarter more for a flow whose extra detail a moving picture does not show.

What keeps the search at that cost: the sum of absolute differences runs on packed 16-bit pairs (AFMF_SAD_INT16, about a third of the ALU work per candidate; the search takes 410 µs without it at display resolution) and a block whose vector from the coarser level already matches keeps it instead of searching 256 candidates again (AFMF_STATIC_BLOCK_SAD; without it the same search takes 1.5 ms, and a game’s share of still blocks decides its gain). The frame is read once whatever the flow resolution: the ingest pass writes the colour ring at frame size and the luma at the flow’s size in the same pass, so half resolution costs no copy and no downscale (AFMF_DIRECT_INGEST=0 puts those back, and about 20 µs with them). All of it runs on a compute queue of the layer’s own (or the game’s last compute queue when the game took them all, as vkd3d-proton does), so it competes for the GPU but never sits in the game’s queue.

Host, on the game’s thread, per present: 11 µs under the validation layer in the headless test: the hook only consumes the game’s semaphores and queues the frame. The slot’s fence, the spare image, recording and the submission (150-200 µs together) run on the layer’s work thread, the two presents and the pacing hold on its presentation thread.

Measured and rejected

Threads and queues

The game’s thread only consumes its semaphores with an empty submission and queues the frame. A work thread waits the slot’s fence, takes the companion’s image, records and submits; a presentation thread presents the generated frame, holds the real one back half a frame and presents it, then acquires the next spare. The pipelines compile on a fourth thread from device creation. On the GPU, everything runs on one compute queue of the layer’s own: within a frame the passes form a dependency chain (ingest, pyramid, search level by level, filter, scale, interpolation), and only the scene change detector’s histogram is independent, so it runs alongside the pyramid with no barrier of its own. A second queue would overlap one frame’s interpolation with the next frame’s ingest, but the next frame arrives milliseconds later and the layer’s whole frame takes under one: the two would never coincide. On a GPU the game keeps at 100 %, what the layer costs is the sum of its dispatches, and that is what the table above measures.

Two things learned from the screenshots’ games that are worth more than a number: id Tech 8 (DOOM) aborts if a swapchain has more than 8 images, so AFMF_EXTRA_IMAGES above 5 kills it (the default, 2, is fine); and RADV_PERFTEST=rtcps, which gives Cyberpunk +40 % in ray tracing, makes RADV crash while compiling DOOM’s ray tracing pipelines. Both are per-game choices, not defaults.

In games

RDNA3 (RX 7800 XT)

Same code, same tests (validation, golden check in both modes, sanitizers), same behaviour in vkcube and in a game. What differs is the cost: at 3440×1440 with the flow at half resolution (AFMF_PERFORMANCE_MODE=performance), 1,070 µs per frame in the headless test and 1,245 µs in game with seven pyramid levels, about three times the RX 9070 XT. The reads and writes of the swapchain images weigh much more than on RDNA4, which is what the defaults now spare it: half resolution and five levels from 1440p up. Expect the 2× to fall short sooner when the game saturates the GPU.

Not compatible with other frame generation layers or injectors

With the lsfg-vk implicit layer installed, Vulkan presentation on the RDNA3 test system hung (no window, 8 fps in vkcube) even with afmf-linux disabled; removing it fixed everything. OptiScaler (PROTON_USE_OPTISCALER, or its DLLs dropped into the game folder), which replaces the game’s upscaler and frame generation inside the process, does not work together with afmf-linux either. Two things generating frames on the same swapchain cannot both be right about which present is which: run one or the other.

The rule that decides what you will see: the ceiling is 2× the base, minus GPU contention when the game already saturates the GPU. A fixed cost of ~0.7 ms per frame weighs more the higher the base is.

Measure it yourself

DISABLE_AFMF=1 %command%                                   # base
AFMF_ENABLE=1 AFMF_LOG=2 AFMF_PROFILE=1 %command% 2>afmf.log

Compare MangoHud’s average and 1 % low in the same scene, and read real fps, no free image and pacing hold from the log. The headless test does the same on a synthetic scene: AFMF_TEST_EXTENT=3440x1440 AFMF_PROFILE=1 ./build/afmf_headless.