CPU Tests: Rendering

Rendering tests, compared to others, are often a little more simple to digest and automate. All the tests put out some sort of score or time, usually in an obtainable way that makes it fairly easy to extract. These tests are some of the most strenuous in our list, due to the highly threaded nature of rendering and ray-tracing, and can draw a lot of power. If a system is not properly configured to deal with the thermal requirements of the processor, the rendering benchmarks is where it would show most easily as the frequency drops over a sustained period of time. Most benchmarks in this case are re-run several times, and the key to this is having an appropriate idle/wait time between benchmarks to allow for temperatures to normalize from the last test.

Blender 2.83 LTS: Link

One of the popular tools for rendering is Blender, with it being a public open source project that anyone in the animation industry can get involved in. This extends to conferences, use in films and VR, with a dedicated Blender Institute, and everything you might expect from a professional software package (except perhaps a professional grade support package). With it being open-source, studios can customize it in as many ways as they need to get the results they require. It ends up being a big optimization target for both Intel and AMD in this regard.

For benchmarking purposes, we fell back to one rendering a frame from a detailed project. Most reviews, as we have done in the past, focus on one of the classic Blender renders, known as BMW_27. It can take anywhere from a few minutes to almost an hour on a regular system. However now that Blender has moved onto a Long Term Support model (LTS) with the 2.83 release, we decided to go for something different.

We use this scene, called PartyTug at 6AM by Ian Hubert, which is the official image of Blender 2.83. It is 44.3 MB in size, and uses some of the more modern compute properties of Blender. As it is more complex than the BMW scene, but uses different aspects of the compute model, time to process is roughly similar to before. We loop the scene for at least 10 minutes, taking the average time of the completions taken. Blender offers a command-line tool for batch commands, and we redirect the output into a text file.

(4-1) Blender 2.83 Custom Render Test

For Blender, we're seeing that SMT gives some extra performance in 64C mode, and comparing TR to TR Pro shows a big jump for the 3955WX over the 3960X despite having fewer cores, whereas the 32c TR is slightly faster than the 32c TR Pro. At 64c, there's little difference.

Corona 1.3: Link

Corona is billed as a popular high-performance photorealistic rendering engine for 3ds Max, with development for Cinema 4D support as well. In order to promote the software, the developers produced a downloadable benchmark on the 1.3 version of the software, with a ray-traced scene involving a military vehicle and a lot of foliage. The software does multiple passes, calculating the scene, geometry, preconditioning and rendering, with performance measured in the time to finish the benchmark (the official metric used on their website) or in rays per second (the metric we use to offer a more linear scale).

The standard benchmark provided by Corona is interface driven: the scene is calculated and displayed in front of the user, with the ability to upload the result to their online database. We got in contact with the developers, who provided us with a non-interface version that allowed for command-line entry and retrieval of the results very easily.  We loop around the benchmark five times, waiting 60 seconds between each, and taking an overall average. The time to run this benchmark can be around 10 minutes on a Core i9, up to over an hour on a quad-core 2014 AMD processor or dual-core Pentium.

(4-2) Corona 1.3 Benchmark

Corona is another bencmark where having SMT enabled does push the results higher, and there's no real difference between TR and TR Pro here. 

Crysis CPU-Only Gameplay

One of the most oft used memes in computer gaming is ‘Can It Run Crysis?’. The original 2007 game, built in the Crytek engine by Crytek, was heralded as a computationally complex title for the hardware at the time and several years after, suggesting that a user needed graphics hardware from the future in order to run it. Fast forward over a decade, and the game runs fairly easily on modern GPUs.

But can we also apply the same concept to pure CPU rendering? Can a CPU, on its own, render Crysis? Since 64 core processors entered the market, one can dream. So we built a benchmark to see whether the hardware can.

For this test, we’re running Crysis’ own GPU benchmark, but in CPU render mode. This is a 2000 frame test, with medium and low settings.

(4-3a) Crysis CPU Render at 320x200 Low

Crysis CPU only has two main limitations: either 32 threads, or 23 cores. We typically run across 16 cores with all threads, and this benchmark tends to prefer cores with high IPC. The 3955WX seems to perform best here, although the Intel options come out ahead.

POV-Ray 3.7.1: Link

A long time benchmark staple, POV-Ray is another rendering program that is well known to load up every single thread in a system, regardless of cache and memory levels. After a long period of POV-Ray 3.7 being the latest official release, when AMD launched Ryzen the POV-Ray codebase suddenly saw a range of activity from both AMD and Intel, knowing that the software (with the built-in benchmark) would be an optimization tool for the hardware.

We had to stick a flag in the sand when it came to selecting the version that was fair to both AMD and Intel, and still relevant to end-users. Version 3.7.1 fixes a significant bug in the early 2017 code that was advised against in both Intel and AMD manuals regarding to write-after-read, leading to a nice performance boost.

The benchmark can take over 20 minutes on a slow system with few cores, or around a minute or two on a fast system, or seconds with a dual high-core count EPYC. Because POV-Ray draws a large amount of power and current, it is important to make sure the cooling is sufficient here and the system stays in its high-power state. Using a motherboard with a poor power-delivery and low airflow could create an issue that won’t be obvious in some CPU positioning if the power limit only causes a 100 MHz drop as it changes P-states.

(4-4) POV-Ray 3.7.1

POV-Ray seems to prefer the 64C/64T variants of Threadripper, but the difference between TR and TR Pro is ever so slightly in favor of the higher frequency TR processors.

V-Ray: Link

We have a couple of renderers and ray tracers in our suite already, however V-Ray’s benchmark came through for a requested benchmark enough for us to roll it into our suite. Built by ChaosGroup, V-Ray is a 3D rendering package compatible with a number of popular commercial imaging applications, such as 3ds Max, Maya, Undreal, Cinema 4D, and Blender.

We run the standard standalone benchmark application, but in an automated fashion to pull out the result in the form of kilosamples/second. We run the test six times and take an average of the valid results.

(4-5) V-Ray Renderer

V-Ray shows benefit from having all 128 threads enabled, and it is interesting here that the performance difference between the 32c and 64c/64t options is next to zero. The W-3175X does well here by contrast, beating out the 32c variants.

Cinebench R20: Link

Another common stable of a benchmark suite is Cinebench. Based on Cinema4D, Cinebench is a purpose built benchmark machine that renders a scene with both single and multi-threaded options. The scene is identical in both cases. The R20 version means that it targets Cinema 4D R20, a slightly older version of the software which is currently on version R21. Cinebench R20 was launched given that the R15 version had been out a long time, and despite the difference between the benchmark and the latest version of the software on which it is based, Cinebench results are often quoted a lot in marketing materials.

Results for Cinebench R20 are not comparable to R15 or older, because both the scene being used is different, but also the updates in the code path. The results are output as a score from the software, which is directly proportional to the time taken. Using the benchmark flags for single CPU and multi-CPU workloads, we run the software from the command line which opens the test, runs it, and dumps the result into the console which is redirected to a text file. The test is repeated for a minimum of 10 minutes for both ST and MT, and then the runs averaged.

(4-6a) CineBench R20 Single Thread(4-6b) CineBench R20 Multi-Thread

CBR20 scales up to 128 threads no problem, but we're seeing a preference in TR over TR Pro in this test where memory bandwidth doesn't matter much.

Power Consumption CPU Tests: Encoding


View All Comments

  • DesireeTR - Wednesday, July 14, 2021 - link

    OK, found the news too. IDK if I can link any other website here other than Anandtech, but look for "Lenovo is Using AMD PSB to Vendor Lock AMD CPUs" from servethehome, dated April 5th 2021. Lenovo P620 with Threadripper Pro was tested and found that they used the strict PSB lock-in like Dell do on their PowerEdge servers. Reply
  • Threska - Wednesday, July 14, 2021 - link

    I think "permanently" is the biggest concern, otherwise it could be a great feature as part of a "root of trust" if the user could control it, especially via hardware modification. e.g. jumper. Reply
  • DesireeTR - Wednesday, July 14, 2021 - link

    Yeah, and if this trend continues, the Ryzen PRO definitely is next on the line getting this PSB. Laptops might be OK, since they use soldered BGA processor anyway, but definitely a big no no for prebuild towers. Reply
  • arashi - Saturday, July 17, 2021 - link

    If it can be overridden like that then it isn't a root of trust anymore. Reply
  • Threska - Saturday, July 17, 2021 - link

    There's the presumption you trust yourself. Reply
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Dear Anandtech: If you ever review the motherboards, I'll relate something a few things I discovered about the Supermicro M12SWA-TF:

    First, it cannot use sleep mode. If you put the computer to sleep, then when you wake it up, the fans will all spin at low RPM, and they will fail to adjust to temperature. HWiNFO64 reports two sets of sensors: one set is direct, and the other is indirect, via the IPMI. After waking from sleep, the direct sensor readings were still reported, but the indirect-via-IPMI sensors were all null. When I logged into the BMC/IPMI, all the sensors were null there too. And when I ran a CPU burn-in after waking from sleep, my CPU temperature quickly climbed higher than normal, and the fans did NOT ramp up their RPM. (I was prepared for this, so I was running only a single-threaded CPU benchmark.)

    Not only did rebooting the computer fix the problem, but so did Windows hibernate. The fact that Windows hibernate fixed the problem told me that the problem was hardware, not OS.

    I contacted Supermicro, and they said this behavior is normal (!!!!!!). They explained that the IPMI controls the fan RPM, but it only connects to the sensors during POST. If you put the computer to sleep, the IPMI loses its connection to the sensors, and it cannot resume that connection until the computer POSTs again.

    So if you review the motherboards, make sure to test the sleep behavior.

    Second, the Supermicro board is programmed with critical low fan RPM threshholds that are lower than Noctua's RPM. If you Google, you'll see a lot of people have problems with using Noctua fans with Supermicro boards. What happens is, the the Noctua fan's RPM will drop below the critical low RPM threshholds, so the Supermicro board will think the fan is failing, and it will quickly ramp the fan up to 100% PWM. Once the fan exceeds the critical low RPM threshold, the alert will end, and the fan will drop its RPM back down again, starting the cycle over. So the fans cycle back and forth between high and low RPM. When I logged into the IPMI, I saw that I every single fan was triggering the low RPM alert every few seconds.

    The solution is to reprogram the IPMI with new critical low RPM thresholds. Supermicro's own IPMI software does NOT allow this, because Supermicro explained to me that some people have overheated and fried their motherboards using insufficient cooling. So I had to use a third-party tool called "ipmitool".

    Usually, ipmitool is obtained via "sudo apt-get install ipmitool". However, I found that the Linux version was unable to establish a connection with my BMC, even though other IPMI tools had no problem with establishing that connection. But other IPMI tools did not have the ability to reprogram the fan thresholds.

    Luckily, the Windows version of ipmitool was able to establish a connection and alter my fan thresholds just fine. The Windows version is available at https://www.dannynieuwenhuis.nl/download-windows-i...

    If you Google, you'll find many, many different websites offering instructions for how to use ipmitool to modify your Supermicro board to be compatible with Noctua fans. I'll just give a few sample lines of code here, in case anyone needs them:

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 upper 1650 1750 1850

    --- FAN1 is the name of the fan header, as labeled in the motherboard manual. Options are FAN1-FAN6 and FANA-FAND.
    --- "lower" numbers are lower non-recoverable, lower critical, and lower non-critical, in that order.
    --- "upper" numbers are upper non-critical, upper critical, and upper non-recoverable, in that order.

    To calculate the thresholds, I did the following:
    First, I looked up Noctua's specs. FAN1 is my Noctua NH-U14S TR4-SP3. According to Noctua, its fan's RPM are 300 +/-20% to 1500 +/- 10% RPM.
    Second, I set the lower non-critical to 300*0.8 (i.e. -20%) and the upper non-critical to 1500*1.1 (i.e. +10%).
    Third, for the critical and non-recoverable thresholds, I just added or subtracted 100%.

    Do the same for every other fan in every other header. I wrote about every line in a .BAT file in Windows, which read like this:

    REM **************************************************************************************************
    REM **********
    REM FAN1 is Noctua NH-U14S TR4-SP3: 300 +/-20% to 1500 +/- 10% RPM
    REM **********

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN1 upper 1650 1750 1850
    REM **************************************************************************************************

    REM **************************************************************************************************
    REM **********
    REM FAN2 is Noctua NF-A15: 300 +/- 20% to 1200 +/- 10%
    REM **********

    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN2 lower 40 140 240
    ipmitool -I lanplus -H <ipaddress> -U <username> -P <password> sensor thresh FAN2 upper 1320 1420 1520
    REM **************************************************************************************************

    and so forth, for every fan header. This successfully solved the problem of the fans triggering the threshold alerts and cycling up and down.
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    "Second, the Supermicro board is programmed with critical low fan RPM threshholds that are lower than Noctua's RPM."

    I meant *higher*. The Supermicro default critical low fan RPM thresholds are *higher* than Noctua's.
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Oh, and because sleep mode is dangerous, threatening to potentially fry your CPU (since the fans no longer respond to temperature), I not only set my computer never to sleep, but I removed sleep from the power options in the start menu. That way, I cannot accidentally put the computer to sleep.

    If you do ever put your Supermicro M12SWA-TF to sleep, you will not receive any alerts that every sensor is null. If you log into the BMC, you'll see every sensor is null, but there are no alerts. And the fans all spin at minimum RPM regardless of your fan setting, and regardless of temperature. So sleep mode appears to have the potential to fry your CPU.
  • Threska - Wednesday, July 14, 2021 - link

    You keep saying "fry" but haven't CPUs had thermal protection for ages at this point? Reply
  • Mikewind Dale - Wednesday, July 14, 2021 - link

    Threska, possibly. But I didn't want to find out.

    At best, sleep mode would cause the computer to constantly downclock or shut down without any clear cause (unless the user realized it was because sleep mode deactivated the IPMI's reporting of the sensors while the sensors themselves were still reporting values to software such as HWiNFO).

Log in

Don't have an account? Sign up now