DaVinci Resolve 14 Performance: Windows vs Linux

Introduction

Our testing involves a large amount of data (828 data points across 138 different tests) and if you do not find dozens of charts appealing, feel free to jump right to the conclusion section.

Test Hardware & Methodology

While our test platform (shown in the chart below) is a pretty standard DaVinci Resolve configuration we often use, there are two things in particular we want to point out. The first is that we opted to use a Core i9 CPU with the X299 chipset rather than a Intel Xeon W or Dual Intel Xeon SP setup such as those used in our recent DaVinci Resolve 14 GPU Scaling: Core i9 vs Xeon W vs Dual Xeon SP article. Those platforms would allow us to test with up to four GPUs, but unfortunately they simply don't play well with CentOS at the moment. We are working on determining what is necessary to get CentOS stable on them, but for now Core i9/X299 is the fastest modern platform for DaVinci Resolve we offer that is also stable with CentOS.

The second is that we used a completely fresh install of CentOS 7.4 rather than the CentOS 7.3 ISO provided by Blackmagic. We actually tried that ISO initially, but we were seeing extremely low performance – often half of what we achieved in Windows 10. We tried updating the kernel and drivers to see if that would resolve the issue, but we ran into major issues with the OS becoming unstable. So instead, we did a fresh install using CentOS 7.4 and installed the video and other drivers ourselves.

All of our test footage is downloaded or transcoded from media that is publicly available. This was done so that anyone can repeat our testing in order to both verify our findings and to see how their current computer stacks up to the latest hardware available. To test each type of footage, we used three different "levels" of grading. The lowest level is simply a basic correction using the color wheels plus 4 Power Window nodes that include motion tracking. The next level up is the same adjustments but with the addition of 3 OpenFX nodes: Lens Flare, Tilt-Shift Blur, and Sharpen. The final level has all of the previous nodes plus one TNR node.

Performance was measured in the Color tab using the built-in FPS counter. After playback was started, we waited 15 seconds for the FPS to stabilize then recorded the lowest FPS number over the next 15 seconds. This method allowed us to achieve highly consistent and replicable results.

For all the RAW footage we tested (CinemaDNG, ARRIRAW, and RED), we not only tested with the RAW decode quality set to "Full Res." but we also tested at "Half Res." ("Half Res. Good" for the RED footage). In our recent articles we saw major differences in both raw FPS but also GPU scaling when using different decode qualities so this is something we are highly interested in.

The footage used in our testing is shown below with links to where you can download it yourself:

While this is by no means every codec available, we do feel that this covers a wide range of footage that many users work with on a daily basis. In the future we may cut down on the number of RED clips and replace them with something like XAVC-S or AVCHD but for now we really wanted to see how the different compression levels impact performance.

4K Media – Live Playback FPS (RAW DATA)

[Click Here] to skip ahead to analysis section

4K DNxHR HQ

4K ProRes 422 HQ

4K ProRes 4444

4K RED 11:1 (Full Res.)

4K RED 11:1 (Half Res.)

4K RED 7:1 (Full Res.)

4K RED 7:1 (Half Res.)

4K CinemaDNG (Full Res.)

4K CinemaDNG (Half Res.)

4K Media – Live Playback FPS (Analysis)

Since our 4K testing contains almost over 300 data points across six different codecs, it can be difficult to pull meaningful conclusions from the raw data. If you tend to use just one of the codecs we tested, we highly recommend looking at just that result, but for a more general take on how DaVinci Resolve performs with each OS we decided to average the results from each test.

Starting with relatively simple color grading using the color wheels and 4 Power Windows, we saw only minor performance differences between Windows 10 and CentOS. Windows has a slight lead (especially when using three GPUs) which is entirely due to the performance when using ProRes 4444. One thing we want to note is that this is the only codec we are using that has a higher 59.94 FPS media and each OS was easily able to maintain >30 FPS with any GPU combination. So while Windows technically has a slight lead here we would really call it a wash.

Adding 3 OpenFX effects, we start to see a bit more of a difference between the two operating systems. Unfortunately, it is a bit of a mixed bag. With the GTX 1080 Ti GPUs, CentOS was a tiny bit faster with one and two GPUs, but Windows 10 took the lead when using three cards. With the Titan V, Windows 10 was about 1 FPS faster on average with a single GPU but no faster with multiple cards. The difference was all 1 FPS or less, however, so once again we would really call this a tie.

Adding TNR, we get our first look at what some may consider to be a real difference in performance. It was only with a single Titan V, but surprisingly Windows 10 came out on top being a bit more than 2 FPS or about 14% faster than CentOS.

6K Media – Live Playback FPS (RAW DATA)

[Click Here] to skip ahead to analysis section

6K DNxHR HQ

6K RED 12:1 (Full Res.)

6K RED 12:1 (Half Res.)

6K RED 7:1 (Full Res.)

6K RED 7:1 (Half Res.)

6K ARRIRAW (Full Res.)

6K ARRIRAW (Half Res.)

6K Media – Live Playback FPS (Analysis)

Our 6K testing is not quite as extensive as our 4K testing, but it still contains over 250 data points across four different codecs. If you tend to use just one of the codecs we tested, we highly recommend looking at just that data but for a more general take on the performance difference between Windows 10 and CentOS we again decided to average the results from each test.

Starting with relatively simple color grading using the color wheels and 4 Power Windows, there is not much to discuss. With this level of grading, we simply were running at full FPS (or very near to it) with every OS and GPU combination we tested.

Adding 3 OpenFX effects, we see a small performance difference with a single Titan V GPU with Windows 10 coming up slightly on top by just over 1 FPS.

Adding TNR is where things start to get really interesting. On average, Windows 10 has a small lead with a single GPU but CentOS ends up being a good amount faster with two or three GPUs. However, there is a lot not shown in this averaged chart. If you look at the individual results, you will notice that the benefit from CentOS mostly comes from the RED 7: and RED 12:1 tests where we used "Full Res." decode quality. The main reason for this is that for those tests, we saw little to no benefit to using multiple GPUs in Windows 10. This is something we noticed in our recent GPU scaling article and appears to be an issue many are reporting when using "Full Res." decode quality with RED footage on the latest versions of DaVinci Resolve.

Overall for this test, Windows has the edge with a single GPU but CentOS is certainly faster on average – especially if you want to use "Full Res." decode quality with RED footage.

8K Media – Live Playback FPS (RAW DATA)

[Click Here] to skip ahead to analysis section

8K DNxHR HQ

8K RED 12:1 (Full Res.)

8K RED 12:1 (Half Res.)

8K RED 9:1 (Full Res.)

8K RED 9:1 (Half Res.)

8K RED 7:1 (Full Res.)

8K RED 7:1 (Half Res.)

8K Media – Live Playback FPS (Analysis)

Once again, if you tend to use just one of the codecs we tested we highly recommend looking at just that data. However, for a more general take on GPU scaling in DaVinci Resolve on each platform we again decided to average the results from each test.

Like the previous sections, the results with relatively simple color grading is not all that interesting. Windows 10 is up to 3-4 FPS faster with a single GPU when using RED 9:1 footage at "Full Res." decode, but other than that there is little difference between the two operating systems.

Adding 3 OpenFX effects actually results in even less difference between Windows 10 and CentOS. Windows did have a bit of an issue with three GPUs in the RED 12:1 "Full Res." decode test, but other than that you would be hard pressed to see a difference between the two operating systems.

With TNR added, the results are actually much more confusing than the chart above shows. On average the two operating systems are about on par with a slight benefit coming from Windows when using a single Titan V. If you drill into the raw results, however, it gets pretty messy.

Just like in the 6K tests, Windows again has a bit of an issue with RED media using "Full Res." decode and at times is up to 6 FPS slower than CentOS. You would think that makes CentOS the clear winner, but strangely CentOS had similar issues – just with "Half Res." decode quality instead. The difference was not quite as dramatic (which is why CentOS comes out slightly on top with multiple GPUs on average), but Windows 10 was often 3-4 FPS faster than CentOS with "Half Res." decode quality.

Conclusion

We went into our testing expecting DaVinci Resolve to perform slightly faster in CentOS 7.4 than in Windows 10 and while there are certain times this is true, the overall reality is a bit more complicated. The main place the two operating systems perform differently is when doing heavy grading with RED footage at different decode qualities. If you use multiple OpenFX and things like TNR, then CentOS is currently better if you work with RED media and want to use "Full Res." decode quality. On the other hand, Windows 10 is overall better if you turn it down to "Half Res." decode quality. Given the fact that especially at 6K and 8K resolutions "Full Res." will often end up giving you around half the FPS of "Half Res." regardless of the hardware, we feel that having better performance at "Half Res." is actually more important for real-world workflows. "Full Res." decode may be ideal, but if you have to choose between working at 9 FPS or 18 FPS you are most likely going to turn down the decode quality in favor of the much higher FPS.

Because of this, we opted to base our final conclusions on the performance when using "Half Res." decode quality with RAW media. As we've stated before, however, if there is a particular codec you use that we tested, we highly recommend looking at the raw results rather than the overall averaged chart below.

For most workloads (shown in the smaller two charts), CentOS and Windows 10 are really about on par. Windows 10 may have a slight lead, but it is small enough to not matter. With things like multiple OpenFX and TNR, however, we definitely saw a performance benefit from using Windows 10 over CentOS in some situations. It was mostly a wash with the GTX 1080 Ti, but with a single Titan V we saw on average about 2.4 FPS higher performance in Windows 10. With two Titan V GPUs we also saw a small difference, but that was only by less than a single FPS.

If you are curious about what the overall results would be if we only used "Full Res." decode quality with the RAW media instead, those results are also available in the charts below:

From a pure performance standpoint, we surprisingly have to give a slight edge to Windows 10. Frankly, however, the difference is small enough that you probably shouldn't base your OS selection on performance alone. If you already have a firm reason for using Linux, then your decision is likely already made for you. However, for those that have not used it before we do want to point out some major considerations that you should take into account if you are considering Linux:

1: Linux has a high learning curve

If you have not used Linux much in the past, be prepared for a lot of Googling and banging your head against the wall. Even something as seemingly simple as installing software usually requires the use of the terminal (similar to Window's command line) and commands that may look like a random string of characters. In addition, if drivers are not installed in the proper manner you can run into issues as serious as the OS no longer booting if you run software updates. The nice thing with Linux is that it's open nature means almost anything can be fixed but we highly recommend only considering Linux if you or someone on your IT staff has extensive experience with it.

2: DaVinci Resolve has very limited audio support in Linux

If you want to use the audio built into your system or even an external DAC, you are most likely going to be out of luck. At the moment, DaVinci Resolve is only able to output audio in Linux through something like a Blackmagic DeckLink or Intensity card. This will send the audio through HDMI or SDI, however, so you also need a grading monitor that supports audio out – hopefully in the form of an audio jack so you can use speakers or a headset rather than any built-in monitor speakers. We do want to note that even with a DeckLink Studio 4K we have had some audio issues in Resolve. At times, the audio would be just fine in the Edit tab, but in the Color tab it was garbled and filled with static. So if audio is something you need, Linux is likely not the right OS for you.

3: Not all related software works in Linux

In particular, we want to point out that Adobe applications like Premiere Pro, After Effects, and Photoshop do not work natively in Linux. Due to this, be sure to double check that any applications you use in addition to DaVinci Resolve support Linux.

4: Not all hardware has Linux support

This could be anything from external devices to hardware integrated into your motherboard. As an example, the Thunderbolt 3 controller built into the X299 system we used in this testing does not currently work in CentOS and actually causes the OS to hang for 10-15 minutes during startup.

This may sound overly critical of Linux, but the truth is that while Linux is not at all bad and in some situations is completely the right choice, for most DaVinci Resolve users Windows is the better option. If there was a significant performance benefit it may be different, but given that Windows is actually slightly better for performance overall, Linux and CentOS in particular is something we are not going to recommend for most of our customers at this time.