Doom OpenGL VS Vulkan Graphics Performance Analysis

 Test Systems and Procedures

---

Before we delve into any testing we would like to take this opportunity to overview our test system.

Test System

• Motherboard – Gigabyte X99-Gaming G1 WiFi LGA 2011-3 Motherboard
• Processor – Intel Core i7 5820K at Stock 3.3GHz
• RAM – 16GB (4 X 4GB) Crucial Ballistix Sport DDR4 2400MHz
• CPU Cooler – Thermaltake Water 3.0 with Gelid GC-Extreme
• Power Supply – BeQuiet Dark Power Pro 11 1200w
• Main Storage Drive – Crucial M550 512GB
• Chassis – Lian Li T80 Test Bench
• Displays – AOC U2868PQU 4K
• Operating System – Windows 8.1 Pro 64 Bit

Driver Details

The latest drivers are always used at the time of testing, but please note reviews and performance articles undergo a scheduling process. This means a new driver could be released on the day of publication. However, this is unavoidable and disclosing the driver versions used is the most transparent way of informing the reader about current performance levels.

Games Used

• Doom

Game Version

It can be quite challenging for any performance analysis to remain completely accurate due to driver enhancements and improved optimisation through post-release patches. Therefore, it’s imperative to provide readers with this information so they can easily determine how the results might differ in a few months time. As you can see, the file version is 6.1.1.706 while the product version is 6, 1, 1, 1916.

Test Procedure

Unfortunately, Vulkan is still relatively new when it comes to compatibility with monitoring software and other benchmarking applications. This means commonly used programs like FRAPS and MSI Afterburner cannot function correctly. It’s a crying shame because FRAPS’ Min/Avg/Max feature is fantastic for DirectX12 testing even if the overlay isn’t displayed during the benchmarking process.

When tackling the Doom benchmark, I went through two methods before settling on the process which seemed to offer the most accurate results. Initially, I used a program called PresentMon which analyses Windows events and relays information regarding the Present data. While you can manually tell the application which executable file to monitor, it requires a command line interface. Despite my lengthy experience using Linux and Windows shell commands, the data didn’t reflect what was happening on screen. In theory, you should be able to open Command Prompt as an administrator, navigate to the PresentMon root folder and start the application with the flags: “presentmon64.exe doomx64vk.exe scroll_toggle -timed 160”. So what does this actually mean? Scroll toggle is an important command which instructs the program when to record the frames. Simply press your keyboard’s Scroll Lock key to start or end the benchmarking run. Furthermore, the timed section will automatically end the benchmark after the number you’ve chosen. After the benchmark is complete, a .CSV file is outputted with an enormous quantity of numbers. In this area, you have to select all the “MsBetweenPresents” data and divide it by 1000.

Honestly, I spent almost two days trying to get PresentMon to work correctly and corroborated the data with Doom’s monitoring overlay hidden in the Advanced menu section. Clearly, there was a huge discrepancy and something seemed amiss. Therefore, I reassessed the program variables, compiled it again and tried running the benchmark with different flags. I even went to the trouble of writing a formula in Excel and LibreOffice to see if the calculation was incorrect. Sadly, nothing changed outside of a margin of error and I decided to use Doom’s performance overlay instead to gauge performance. In the future, FRAPS will be updated to support Vulkan and DirectX 12 which makes it much easier to benchmark the latest APIs.

Since Doom hasn’t got an integrated benchmarking tool, there’s a wider margin for error than usual and performance could vary depending on which section of the game is tested. I did some preliminary benchmarks across different levels and found one area early in the first level which involves a scripted sequence and demanding lighting effects. Not only that, there’s a large explosion which gives us a great insight into the minimum frame-rate and I’m fairly confident about the data gathered. If you’re interested, the benchmarking section is in level one just after you’ve explored a corridor.

The game’s options menu is filled with a huge number of tweaks which allows the end-user to change the monitor aspect ratio, V-Sync, AA type, and even enable a colourblind mode. The one important element to take note of here is the TSSAA (8TX) setting which determines if asynchronous compute is being utilised. Only when TSSAA is switched on or AA has been disabled completely will allow this important feature to be used.

On the advanced tab, you can cycle between the OpenGL and Vulkan APIs although this requires the game to reboot. During the testing, I selected the Ultra preset and increased the Decal Filtering to x16. I’m a little perplexed why this is automatically rated at x8 but it might have something to do with the Nightmare graphics mode. This can only be selected through the advanced tab and there’s no Nightmare preset. I decided not to use this hidden mode since most people will be employing the Ultra preset and the Nightmare option might have impacted on the gains possible using Vulkan compared to OpenGL. To clarify, the article is about judging AMD versus NVIDIA performance when swapping APIs and not just a traditional game analysis.

Further down the advanced section, the show performance metrics setting is visible and you can tweak it to display detailed per core loads or a basic overlay of the GPU’s current frame-rate. To keep things clean, the High setting was deployed.