Under The Hood for Displays: Custom Resolutions, Freesync Improvements, & Framerate Target Control

Continuing our look into Crimson’s new features, AMD has also implemented some new & improved functionality specifically targeted at displays. The company has been more aggressive about display technologies and features since embarking on their Freesync project, and that is reflected in some of the changes made here.

Custom Resolution Support

First and foremost, AMD has finally (and at long last) implemented support for custom resolutions within their control panel. Custom resolution support is something of a niche feature – most users will never find it, let alone need it – however it’s extremely useful for those users who do need it. In our own case, for example, we use this feature with our Sharp PN-K321 4K monitor in order to run 1440p@60Hz on it, as the monitor doesn’t explicitly support that setting and Windows would rather upscale 1440p to 2160p@30Hz when left to its own devices.

Custom resolution support is another area where AMD is catching up with NVIDIA, as the latter has supported custom resolutions for several years now. In the meantime it’s been possible to use third-party utilities such as Custom Resolution Utility with AMD’s drivers to force the matter, but bringing support within AMD’s drivers is still a notable improvement.

AMD has never previously supported this feature in part due to the very low but nonetheless real risk of damage. If given video settings it can’t use, a properly behaving monitor should simply reject the input. However not all devices are perfect, and it is possible (however unlikely) that a monitor could damage itself trying to run with unsupported settings. This is why for both AMD and NVIDIA, custom resolutions come with a warning and are not covered under their respective warranties.

On a side note, one thing that was interesting to find was that this was one of the features not implemented in Radeon Settings. Rather the custom resolution control panel is part of the pared down Catalyst Control Center, now called Radeon Additional Settings. Considering that AMD never supported custom resolutions until now, it’s a bit surprising that they’d add it to CCC rather than Radeon Settings. But I suspect this has a lot to do with why CCC is still in use to begin with; that not all of the necessary monitor controls are available in Radeon Settings at this time.

Freesync Improvements: Low Framerate Compensation

With Omega AMD included initial support for Freesync, and now with Crimson AMD is rolling out some new Freesync functionality that changes how the technology works at the GPU level.

NVIDIA, never one to shy away from throwing barbs at the competition, has in the past called out AMD for how Freesync has handled minimum refresh rates. Specifically, that when the framerate falls below the minimum refresh rate of the monitor, Freesync setups would revert to non-Freesync operation, either locking into v-sync operation or traditional v-sync off style tearing depending on whether v-sync was enabled. Though in some ways better than what NVIDIA offered at the time (v-sync control) on the other hand it meant that the benefits of Freesync would be lost if the framerate fell below the minimum. Meanwhile NVIDIA, though not publishing exactly what they do, would seem to use some form of frame repeating in order to keep G-Sync active, repeating frames to keep variable refresh going rather than working at the minimum refresh rate.

This is something AMD appears to have taken to heart, and while they don’t specifically name NVIDIA in their presentation, all signs point to it being a reaction to NVIDIA’s barbs and marketing angle. As a result the Crimson driver introduces a new technology for Freesync which AMD is calling Low Framerate Compensation (LFC). LFC is designed to directly address what the GPU and Freesync monitor do when the framerate falls below the minimum refresh rate.

In AMD’s slide above, they list out the five refresh scenarios, and the two scenarios that LFC specifically applies to. So long as the framerate is above the minimum refresh rate, Freesync is unchanged. However when the framerate falls below the minimum, AMD has instituted a series of changes to reduce judder. Unfortunately, not unlike NVIDIA, AMD is treating this as a “secret sauce” and isn’t disclosing what exactly they’re doing to alleviate the issue. However based on what we’re seeing and AMD’s description (along with practical solutions to the problem), our best guess is that AMD is implementing frame repeating to keep the instantaneous refresh rate above the monitor’s minimum.

Frame reuse is simple in concept but tricky in execution. Not unlike CrossFire, there’s a strong element of prediction here, as the GPU needs to guess when the next frame may be ready so that it can set the appropriate refresh rate and repeat a frame the appropriate number of times. Hence, in one of the few things they do say about the technology, that AMD is implementing an “adaptive algorithm” to handle low framerate situations. Ultimately if AMD does this right, then it should reduce judder both when v-sync is enabled and when it is disabled, by aligning frame repeats and the refresh rate such that the next frame isn’t unnecessarily delayed.

The good news here is that this is a GPU-side change, so it doesn’t require any changes to existing monitors – they simply receive new variable refresh timings. However in revealing a bit more about the technology, AMD does note that LFC is only enabled with monitors that have a maximum refresh rate greater than or equal to 2.5 times the minimum refresh rate (e.g. 30Hz to 75Hz), as AMD needs a wide enough variable refresh range to run at a multiple of framerates right on the edge of the minimum (e.g. 45fps). This means LFC can’t be used with Freesync monitors that have a narrow refresh rate, such as the 48Hz to 75Hz models. Ultimately owners of those monitors don’t lose anything, but they also won’t gain anything with LFC.

As it stands we’ve only had a very limited amount of time to toy with Freesync on the new drivers, but what we’re seeing so far looks solid. But we’re definitely curious in seeing how daily Freesync users respond to this.

Finally, along with the LFC news, for the Crimson driver release AMD has offered a brief update on the status of Freesync-over-HDMI, reiterating that the company is still working on the technology. AMD first demonstrated the concept at Computex 2015 back in June, and while they still have a long way to go before it can make it into a retail product, the company continues to believe adaptive-synchronization is a viable and meaningful addition for HDMI.

Framerate Target Control: Wider Ranges

Back in June for the launch of the Radeon R9 Fury X, AMD introduced a new frame limiting feature called Framerate Target Control (FRTC). FRTC offered an alternative to v-sync, allowing users to cap the framerate of a game at an arbitrary framerate, selected via AMD’s control panel. While FRTC worked it had one unfortunate limitation, and that was that it only worked over a very limited range – 55fps to 95fps. Though this was sufficient to cap the framerate right below 60fps or directly above it, users have been asking for wider ranges to support higher framerate monitors or to limit a game to even lower framerates such as 30fps.

For Crimson AMD has gone ahead and widened the range of FRTC. It can now cap a game at between 30fps and 200fps, a range over four-times as wide. At the same time AMD has mentioned in our briefing that they’ve also done some additional work to better restrict GPU clockspeeds when FRTC is in use to maximize the power savings from using it to limit the amount of work the GPU does. Now the GPU will operate at a lower clockspeed more often, increasing the amount of power saved versus letting a video card run uncapped.

Under The Hood: DirectX 9, Shader Caching, Liquid VR, and Power Consumption Radeon Settings: The New Face of AMD’s Drivers


View All Comments

  • tuxfool - Tuesday, November 24, 2015 - link

    If You never get that, then clearly it isn't happening to anybody else. Reply
  • Glenn37216 - Tuesday, November 24, 2015 - link

    Me neither .. I have 970's , 980's , 980ti's ... hmm maybe he needs to quit going to pornhub so much ! Reply
  • Alexvrb - Tuesday, November 24, 2015 - link

    Nobody likes a quitter! Besides, it doesn't crash on an AMD GPU- I MEAN-- nevermind... Reply
  • looncraz - Tuesday, November 24, 2015 - link

    I've had to fix issues like that on both sides when using multiple monitors.

    This new driver from AMD, though, is awesome! I can now set a simple low global clockspeed, then set speeds per game, without all of my previous profile work. And framerate control is fantastic, I set the default at 60fps, then set just a few games to go faster. My default clocks are -45%, -40% lower power, and 500MHz RAM (default is 1250). It goes back up to stock for BF4 and Hitman. Other than that, nothing I play requires the full power of an R9 290 (not even Crysis), and some games hit stupidly high framerates.
  • AS118 - Tuesday, November 24, 2015 - link

    Yeah, that's true. I've used Nvidia and AMD drivers, and while both are actually pretty good, I noticed that Nvidia's faster drivers can be buggier, even if they're WHQL, whereas AMD's instabilities are usually found more in the betas. They may take longer to put out WHQL drivers, but I find that they're more stable because of it.

    That said, near about 90% of the time, I've had no trouble with Nvidia or AMD drivers, even the beta ones. I don't use Crossfire / SLI or the latest tech though. That generally leads to more issues, especially if you combine them (using 2 of the just released cards in Crossfire, etc.)
  • dkizzy - Tuesday, November 24, 2015 - link

    Dude forget these haters. I still have that problem on my BenQ XL2420Z 144hz. I have to run it at 120hz to get the card to clcok down on the desktop. Reply
  • looncraz - Tuesday, November 24, 2015 - link

    People don't seem to realize that even AMD's beta drivers would probably pass WHQL testing. Doesn't make much sense to have a main branch that isn't in an acceptable state. The beta drivers are just branches of the WHQL'd drivers with a few fixes applied.

    More WHQL drivers means absolutely nothing.
  • bolek - Thursday, December 17, 2015 - link

    This. No drivers, beta or not, are released without running WHQL tests internally. The official WHQL certification matters for OEMs like Dell or HP, but has zero impact on gamers. Reply
  • Dalamar6 - Wednesday, November 25, 2015 - link

    Both companies have their ups and downs, but there is no excuse for AMD's crippling rolling release linux distributions because they never update drivers. For months/years on end. Reply
  • Oxford Guy - Thursday, November 26, 2015 - link

    Don't forget the magical "mouse does nothing for a while" syndrome that was also a virtue of at least one, if not more, of their driver releases. Reply

Log in

Don't have an account? Sign up now