AMD's Chill: Driver feature as a miracle weapon for saving power?

1 - Chill und OCAT - zwei neue AMD-Features 2 - Chill im Praxistest und Fazit

As part of the new driver, AMD with Chill offers an interesting feature that can greatly reduce the power consumption depending on the situation, keep the card cooler and also offer advantages. With OCAT, a new, free benchmark tool that masters DirextX 12 and OpenGL and has no problems with UWP applications is added.

In addition to the many minor and major innovations in AMD's new Radeon ReLive driver, this test will focus on the new Feature Chill, wherewe will of course make the appropriate benchmarks with OCAT, AMD's new benchmark tool.

But let's get to the trick AMD has devised to significantly reduce performance in everyday gaming. The fact that this has more or less strong effects depending on the situation is due to the operating principle of load-dependent frame rate limitation. But more on that.

Activating Chill and Restrictions

You can activate Chill first of all via the Radeon settings. You can find the feature in the Wattman, where you can activate or deactivate it globally (default setting) – regardless of the other settings in the game profiles.

Which brings us to the (current) limitations: Chill works quite neatly, but only for DirectX-9 and DirectX-11 games. If you have installed the profiles during the installation as well as the drivers, the desired game can be edited in the profile and you can activate Chill and even provide it with desired target frame rates, for example to raise the minimum to 60 FPS or more.

As tempting as it may sound, the whole thing has a tiny catch at the moment: Similar to Nvidia's Ansel, there is only a select number of suitable games available at the beginning. This so-called whitelist can of course still fill up, but there is still some emptiness in the portfolio in terms of brand-new blockbusters. But what is not can still be.

How it works and features

AMD hasn't revealed much so far, so we were a little on our own and in the end we were left with only conjecture. First of all, however, the calmer and more unmoved the scene is, the lowerthe FPS number. As a direct consequence, this logically results in a lower power consumption. But to get this flowing, AMD has to reach a little deeper into the trick box.

To prevent the whole thing from being perceived subjectively as slower screen output, AMD's driver reacts very flexibly and sensitively to input devices (mouse, keyboard, gamepad) as well as major changes to the scene (movements) itself. As soon as it is assumed that higher FPS rates are needed, Chill lifts the brake more or less intelligently.

In order to at least get a little bit of attention to the mode of action, we have selected a total of three scenes, which we will not only benchmark, but also measure high resolution in terms of power consumption for one minute at a time. We will try to explain the following in a somewhat simplified way in order to remain as comprehensible as possible.

The first benchmark is certainly the most accommodating to Chill. The scene, which is part of the output viewport, remains largely unchanged. The Kamara as a child object within the scene remains statically at its location and also the Z-Buffer is rarely touched at all. The acting person (actor) is nothing more than a kind of animated mesh that is brought to life by means of scripts – only that one stays here almost continuously in a resting position.

Test 1 – Fixed location, hardly any movements

In the second scene, we rotate the camera 360 degrees back and forth around the Y axis (vertical axis). Then we let the actor jump up as an animated mesh within the scene in front of the now standing camera and perform two combat movements. After that, this procedure starts again until the minute is over. We expect a slightly higher power consumption, because the recalculated image range is relatively small, so only the actor jumps. Also the rotation at the place only resorts to the finished scene.

Test 2: Rotate the camera around its own axis and move the actor

But what happens when you move the camera and the actor extensively through the open world (on all three axes) and the actor is also animated (running motion)? The forest has always been a challenge for the graphics card with The Witcher 3 and since everything has to be recalculated constantly, the savings possibilities here are probably the least. But we will measure all of this in the same way.

Review 3 – Continuous movement of the camera in the scene

Chill also harmonizes very well with FreeSync, which is very suitable for the smoothest and smoother screen output. In order to guarantee the general validity of the benchmarks, we have again dispensed with FreeSync for the actual runs. But it's a feature that you can (and certainly should) indulge in.

All the aspects that Chill actively changes ultimately have an impact on AMD's Power Estimation Engine and can thus also have a direct influence on the supplied performance via the Arbitrator in combination with the remaining influences (sensor values, etc.). This can then lead to more or less large-scale austerity measures – depending on the situation, of course.

The remaining improvements advertised by AMD in terms of chill are difficult to assess subjectively. For example, AMD wants to significantly increase the synchronicity of frame output by trying to adjust the times when the rendered frame appears on the screen to the rhythm of GPU and CPU idle time.

This should also result in more delay-free playback because there are fewer pre-rendered frames in the queue. Ergo is also more likely to output the frame to which a current action refers. Sounds good and purely subjectively it also works quite well. At least it was astonishing that even lower FPS rates felt quite fast in the input.

Benchmarking with AMD's OCAT

With OCAT, AMD releases a free tool that masters all current APIs. This ranges from DirectX 9 to DirectX 12 and also includes OpenGL and volcano. UWP applications are also not an issue. However, OCAT is not really new, because in the end it is nothing more than PresentMon with an AMD-owned GUI, which has been stylishly adapted to the Radeon software.

The program has a similar functionality to PresentMon and also generates identical CSV files in record mode. This means that these files can be read in our own interpreter tool even without obstacles, which of course is extremely accommodating to the evaluation and graphical processing. However, unlike our own software, what is (still) missing is the simple creation and saving of your own profiles.

As a graphics card, we consciously choose an MSI RX 480 Gaming 8G, as this card with its almost 190 watts maximum power consumption is the most likely to show the potential for savings. Our current standard graphics card test system provides the rest of the hardware.