AMD AFMF TESTED – AMD Fluid Motion Frames is WILD… (LATENCY + FPS)

You might have heard about AMD’s AFMF feature recently – that being AMD Fluid Motion Frames, which yes means saying AMD AFMF is like saying RIP in peace. AFMF is heralded as the one-click way to double your framerates in basically any game. But, like, what actually are “Fluid Motion Frames”? Well, in short, it’s frame generation – the same idea as NVIDIA’s DLSS Frame Generation – but it’s done in-driver. That means that, much like Radeon Super Resolution, the game doesn’t need to support AFMF or frame generation at all. In fact, the game, and even performance monitors like FrameView or OCAT won’t know anything about that generation happening. Now, it does have a few limitations. It only works on RX 6000 and RX 7000 cards, and 700M graphics on APUs – I’m testing with an RX 7600 here – and something I only found out after starting to test: it only supports DirectX 11 and 12 games. No Vulkan support, which means Rainbow Six Siege does not work. Strangely, even when I launched Siege in DirectX 11 mode, it still said it wasn’t supported. Perhaps AMD has just blacklisted the Siege EXE – who knows. But, for a plethora of reasons I’ll explain later, I switched to Starfield instead. Oh and it’s worth noting that you’re meant to have both HDR and VSync disabled for this too. Right, let’s look at some data!

First, as a baseline, I tested the system with just Radeon Anti-lag on. It’s a feature I’d recommend enabling regardless of any other settings, assuming you have an AMD GPU anyway, so I’d consider that a fairly baseline setup. The next test was just turning AFMF on – so the only two AMD features enabled were Anti-Lag and AFMF. Lastly, I also enabled their new HYPR-RX mode, which turns on every tool in the toolbox, including Radeon Super Resolution. As for recording data, for latency as always I’m using the Open Source Latency Testing Tool I developed (and sell over on OSRTT.com by the way, link in the description), and for FPS, as mentioned tools like PresentMon and FrameView (which is just PresentMon with an NVIDIA wrapper) won’t detect the total performance here, so I’m using AMD’s own driver-based performance monitor. One extra advantage of that is that it’ll report how much latency is added by the frame generation, so I’ve included that data here too.

So, what’s the results? Well if we look at the performance data first, you can see how effective AFMF really is. We go from 104 FPS average, to a whopping 166 with just AFMF enabled. Enabling HYPR-RX and all those other features like RSR added another 10 FPS or so on top, and gave a significant boost in the 1% low results too – a full 30 FPS higher there. Clearly, enabling AFMF is a no brainer then, right? Well, if you notice that extra number at the bottom there, the FrameGen latency average – that’s pretty important. Obviously, with no frame generation enabled, we are adding zero latency to our gaming experience. With AFMF enabled though, you’re looking at 20 milliseconds of ADDED latency. If you’ve watched any of my latency guide videos, you’ll know that 20 milliseconds is an awfully long time to be ADDING on top of the game itself. Let’s look at the latency results in fact. As expected for a gaming that isn’t running overly fast – even on a 165Hz display, 100 FPS means new frames every 10 milliseconds, so it looks like Starfield on all low settings with FSR2 enabled takes about two and a half frames to render an input. That’s pretty slow as-is, but when you add AFMF on top of that, you end up with a frankly appalling 50 millisecond average delay between giving an input, to that input being shown on screen. For a game like Starfield, it’s a genuine toss-up whether the improved smoothness from the artificially increased framerate is worth it over a doubling of the input delay. The big problem here is that the higher the latency, the harder it is to aim with any accuracy. If you spend most of your time in the dialog options and running away from fights, AFMF is the tool for you. If you want the competitive advantage in a gunfight, you might want to switch AFMF off. 

Now I was going to leave it there and move on, but in the interest of thoroughness, I tested two more games to see how they handle it. The first is the other super-intensive single player game everyone loves to hate, Cyberpunk 2077. On the medium preset, which uses FSR 2.1 by default anyway, unsurprisingly, AFMF and the HYPR-RX mode offer significantly better performance than stock – like this is a 60% improvement on average. Impressively, this RX 7600, even at 1440p, still offered 121 FPS on average, but it’s very obvious you get a smoother experience with AFMF on. Interestingly, likely thanks to the framerates being pretty similar, the framegen latency is about the same, this time at around 18 milliseconds on average. That’s confirmed when we look at the latency chart too, where the stock results are reasonable at 28 milliseconds on average, versus both AFMF results at an astonishingly sluggish 54 milliseconds on average. This one, at least on this 7600 on the medium preset anyway, is a little harder to justify. Cyberpunk relies a lot heavier on gunplay and action, and hell even trying to drive with DOUBLE the latency just isn’t going to be a great experience. If you care more about visual fidelity, and so are more likely to be playing at higher settings, and therefore lower framerates, then I think that tips the scales in favour of using AFMF. 

Lastly, I also tested CS2. I was almost certain this would be a wildly different set of results – and conclusions – to Starfield and Cyberpunk, but honestly I couldn’t have predicted the results I got. Starting with the FPS data, it looks like AFMF made the gaming experience considerably slower. Like, we lost over 100 FPS on average here by turning AFMF on. We did gain a bit of stability, bringing the 1% lows right up to the average, rather than around half the average with AFMF off, but losing performance isn’t a great sign. I have to assume that part of that has to do with the framegen latency figure – 11 milliseconds is way, way too high for a 2 millisecond frame time. There is clearly a decent bit of time taken to analyse and render the fake frame, then to display it. And, all that work is for nought, because not only do you lose performance, your inputs take nearly THREE TIMES LONGER TO REGISTER! We go from an average end to end latency of 9.7 milliseconds – a fantastic result – to 25.9 milliseconds, which for a game like CS2 is a death sentence. These two graphs should be all the evidence you need to NOT USE AFMF OR HYPR-RX WITH CS2. Don’t do it. Just don’t. It’s worse in every single way. Ok? Got it? Good.

Something I want to take a second to explain is why these features – whether they come from AMD’s open source arms, or NVIDIA’s proprietary claws – will ALWAYS add latency. It’s a fundamental function of how they work. Basically, to be able to generate a somewhat useful intermediary frame, it needs to be able to look at the current frame, and the next one. Let me visualise that here – so we’ve got the current frame that’s on its way to the display, that’s all ready to go. Now any type of frame generation feature, AFMF, DLSS FrameGen, it doesn’t matter, it has to wait around for the GPU to draw the next frame. Then, instead of just pushing that new frame straight out to the display – as low latency as possible – the FrameGen tool then compares the two and renders that inbetween frame. That will take some time to do too, as we’ve seen from the data, and then it will send that fake frame out to the display. Then, after all this time waiting, the next frame actually gets shown. The fact that these features have to see what the next frame looks like to interpolate between them to create an extra one in the middle means that these features will ALWAYS add latency, and the only optimisation is how quickly they can do that interpolation. That’s why even NVIDIA’s in-engine version takes just as long.

Interestingly though, there is one key design choice I’m yet to talk about here, which is that AMD has chosen to disable AFMF during fast movement. Specifically, this seems to only apply to mouse movement. Testing in Starfield, just walking around but not moving the mouse shows the full 150 FPS or so, but the second I start moving the mouse, the FPS drops down to the native 90 FPS instead. In theory, this should give you the best of both worlds, right? I mean for just walking around you get all that extra performance, but when you’re in intense combat, it disables itself for that quicker reaction times, right? Well, as far as I can tell, no. The first problem is that if this is tied to mouse movement, I can’t think of a time where when playing Starfield I wouldn’t be moving the mouse to navigate the world. That seems to defeat the purpose of the feature to me. Second, the latency test I was doing was a mouse move. It should have been disabling itself for EVERY test result, but as far as I can see, it stayed active the whole time – or at least the latency stuck around. Whether this is because OSLTT basically instantly shifts the mouse position, giving AFMF no time to turn off first, or because the latency part is there the whole time, I can’t really answer, but it doesn’t seem all that appealing to me. 

With that said, the whole point of the “Fluid Motion Frames” is to provide, well, ‘fluid motion’, and that’s something that’s worth viewing subjectively, as well as objectively, so let’s have a play in Starfield and see what it actually feels like to play with.

[You’ll have to watch the video to see what I think about that in-person!]

I think it’s time to wrap this up with some closing thoughts. Frame Generation tech is pretty cool, although certainly has some drawbacks. On the one hand, it’s literally free performance, but on the other it’s a bass-ackwards solution to increasing your framerates. AFMF itself is a pretty clever implementation – the fact that it’s baked into the driver means it works with a bunch of games, without the game developers having to do literally anything to support it. That means that regardless of if you want to play Starfield, CS2 or Train Sim World 4, you can boost your FPS with AFMF. The catch that it only works with DirectX games means games like Rainbow Six Siege are off the table – although much the same as CS2, you wouldn’t want to use it on that anyway. Strangely, even when I swapped to the DirectX 11 mode, AFMF still wouldn’t enable, claiming I was using an unsupported API. Not sure what’s going on with that one. Anyway, the on/off behaviour is clever, but can lead to stuttering and a bit of a janky experience. Lastly, on the latency front, it’s a pretty big ask – double your latency for 50% more performance. For some games, like Starfield, I can see that tradeoff being worth it, but for anything even remotely competitive, there’s no chance I’d leave this on.