RX 6800 XT vs. RTX 3080. Part 2/2: Non-gaming tests

Ľubomír Samák

3 years ago

Analysis of 12 V subcircuit power supply

Without application/computational tests, graphics card tests would be incomplete. Therefore, we will focus on this area outside of gaming that most hardware magazines neglect. We understand the reasons, there are several of them, but even so, it is possible with a little effort to make at least a few measurements. So hopefully they will also help multimedia creators in choosing the right graphics card.

Methodology: performance tests

Testing the graphics card comprehensively, even in terms of computing power, is more difficult than drawing conclusions from the gaming environment. Just because such tests are usually associated with expensive software that you don’t just buy for the editorial office. On the other hand, we’ve found ways to bring the available computing performance to you. On the one hand, thanks to well-built benchmarks, on the other hand, there are also some freely available and at the same time relevant applications, and thirdly, we have invested something in the paid ones.

The tests begin with ComputeBench, which computes various simulations (including game graphics). Then we move on to the popular SPECviewperf benchmark (2020), which integrates partial operations from popular 2D and 3D applications, including 3Ds max and SolidWorks. Details on this test package can be found at spec.org. From the same team also comes SPECworkstation 3, where GPU acceleration is in the Caffe and Folding@Home tests. You can also find the results of the LuxMark 3.1 3D render in the graphs, and the remarkable GPGPU theoretical test also includes AIDA64 with FLOPS, IOPS and memory speed measurements.

For obvious reasons, 3D rendering makes the largest portion of the tests. This is also the case, for example, in the Blender practical tests (2.91). In addition to Cycles, we will also test the cards in Eevee and radeon ProRender renderers (let AMD have a related test, as most are optimized for Nvidia cards with proprietary CUDA and OptiX frameworks). Of course, an add-on for V-ray would also be interesting, but at the moment the editorial office can’t afford it, we may manage to get a “press” license in time, though, we’ll see. We want to expand application tests in the future. Definitely with some advanced AI testing (we haven’t come up with a reasonable way yet), including noise reduction (there would be some ideas already, but we haven’t incorporated those due to time constraints).

Graphics cards can also be tested well with photo editing. There is already a large number of various filters with GPU acceleration support, but the possibility of convenient repeated measurements is important. This quite well allows blur in Photoshop and in the cheaper Affinity. We implement it on a large photo with a resolution of 62 Mpx, to which we apply a script via Macro Recorder with a high frequency of steps there (250 px) and back (0 px), while recording average fps. In Lightroom, there are notable color corrections (Enhance Details) of raw uncompressed photos. We apply these in batches to a 1 GB archive. All of these tasks can be accelerated by both GeForce and Radeon.

From another perspective, there are decryption tests in Hashcat with a selection of AES, MD5, NTLMv2, SHA1, SHA2-256/512 and WPA-EAPOL-PBKDF2 ciphers. Finally, in the OBS and XSplit broadcast applications, we measure how much the game performance will be reduced while recording. It is no longer provided by shaders, but by coders (AMD VCE and Nvidia Nvenc). These tests show how much spare performance each card has for typical online streaming.

There are, of course, more hardware acceleration options, typically for video editing and conversion. However, this is purely in the hands of encoders, which are always the same within one generation of cards from one manufacturer, so there is no point in testing them on every graphics card. It is different across generations and tests of this type will sooner or later appear. Just fine-tuning the metric is left, where the output will always have the same bitrate and pixel match. This is important for objective comparisons, because the encoder of one company/card may be faster in a particular profile with the same settings, but at the expense of the lower quality that another encoder has (but may not have, it’s just an example).

Methodology: how we measure power draw

We have been tuning the method of measuring power draw for quite a long time and we will also be tuning it for some time. But we already have gimmicks that we can work with happily.

To get the exact value of the total power draw of the graphics card, it is necessary to map the internal power draw on the PCI Express slot and the external one on the additional power supply. For the analysis of the PCIe slot, it was necessary to construct an in-between card on which the power draw measurement takes place. Its basis is resistors calibrated to the exact value (0.1 Ω) and according to the amount of their voltage drop we can calculate the current. We then substitute it into the formula for the corresponding value of the output voltage ~ 12 V and ~ 3.3 V. The voltage drop is so low that it doesn’t make the VRM of the graphics card unstable and the output is still more than 12/3.3 V.

We measure power consumption on the card between the graphics card and the PCI Express slot. Rado Kopera took care of the design and implementation (thank you!)

We are also working on a similar device for external power supply. However, significantly higher currents are achieved there, longer cabling and more passages between connectors are necessary, which means that the voltage drop will have to be read on an even smaller resistance of 0.01 Ω, the current state (with 0.1 Ω) is unstable for now. Until we fine-tune it, we will use Prova 15 current clamp for cable measurements, which also measures with good accuracy, they just have a range of up to 30 A. But that is also enough for the OC version of the RTX 3090 Gaming X Trio. If a card is over the range, it is always possible to split the consumption measurement (first into one half and then into the other half of the 12 V conductors).

And why bother with such devices at all when Nvidia has a PCAT power draw analyzer? For complete control over the measurements. While our devices are transparent, the Nvidia’s tool uses the processor that can (but of course does not have to) affect the measurements. After testing the AMD graphics card on the Nvidia’s tool, we probably wouldn’t sleep well.

To read and record measurements, we use a properly calibrated multimeter UNI-T UT71E, which exports samples to XLS. From it we obtain the average value and by substituting into the formula with the exact value of the subcircuit output voltages we obtain the data for the graphs.

We will analyze the line graphs with the waveforms for each part of the power supply separately. Although the 3.3 V value is usually negligible, it needs to be monitored. It is difficult to say what exactly this sub-circuit powers, but usually the consumption on it is constant and when it changes only with regard to whether a static or dynamic image is rendered. We will measure the consumption in this article during xxx rendering, decoding 4K@60 fps video with a bit rate of 60 Mb in online format VP9 (Google Chrome) and HEVC (VLC) and idle mode with two 4K@60 Hz monitors. And finally at 3.3 V sub-circuit even when the computer is hibernated. You measure the same power draw here as when the computer is turned off, but the motherboard remains powered by the power supply.

Noise measurement…

Noise, as well as other operating characteristics, which we will focus on, we’re measuring in the same modes as consumption, so that the individual values overlap nicely. In addition to the level of noise produced, we also record the frequency response of the sound, the course of the GPU frequencies and its heating.

In this part of the methodology description, we will present something about the method of noise measurement. We use a Reed R8080 sound level meter, which we continuously calibrate with a calibrated Voltcraft SLC-100 meter. A small addition to the sound level meter is a parabola-shaped collar, which has two functions. Increases the sensitivity to distinguish the sound produced even at very low speeds. It is thus possible to better compare even very quiet cards with the largest possible ratio difference. Otherwise (without this adjustment) it could simply happen that we measured the same noise level across several graphics cards, even though would actually be a little different. This parabolic shield also makes sense because, from the outer convex side (from the back), it reflects all the parasitic sounds that everyone who really aims for accuracy of the measurements struggles with during the test. These are various cracks of the body or objects in the room during normal human activity.

To ensure the same conditions when measuring the noise level (and later also the sound), we use acoustic panels with a foam surface around the bench-wall. This is so that the sound is always reflected to the sound level meter sensor in the same way, regardless of the current situation of the objects in the test room. These panels are from three sides (top, right and left) and their purpose is to soundproof the space in which we measure the noise of graphics cards. Soundproofing means preventing different reflections of sound and oscillations of waves between flat walls. Don’t confuse it with sound-absorbing, we’ve had that solved well in the test lab for a long time.

During the measurements, the sound level meter sensor is always placed on a tripod at the same angle and at the same distance (35 cm) from the PCI Express slot in which the graphics card is installed. Of course, it’s always closer to the card itself, depending on its depth. The indicated reference point and the sensor angles are fixed. In addition to the “aerodynamic noise” of the coolers, we also measure the noise level of whining coils. Then we stop the fans for a moment. And for the sake of completeness, it should be added that during sound measurements, we also switch off the power supply fan as well as the CPU cooler fan. Thus, purely the graphics card is always measured without any distortion by other components.

… and the frequency response of the sound

From the same place, we also measure the frequency of the sound produced. One thing is the noise level (or sound pressure level in decibels) and the other thing is its frequency response, coloration.

According to the data on the noise level, you can quickly find out whether the graphics card is quieter or noisier, or where it is on the scale, but it is still a mix of different frequencies. Thus, it does not say whether the sound produced is more booming (with a lower frequency) or squeaking (with a high frequency). The same 35 dBA can be pleasant but also unpleasant for you under certain circumstances – it depends on each individual how they perceive different frequencies. For this reason, we will also measure the frequency response of the sound graphics card in addition to the noise level, via the TrueRTA application. The results will be interpreted in the form of a spectrograph with a resolution of 1/24 octave and for better comparison with other graphics cards we will include the dominant frequency of lower (20 – 200 Hz), medium (201 – 2000 Hz) and higher (2001 – 20 000 Hz) sound spectrum into standard bar graphs. For measurements, we’re using a calibrated miniDSP UMIK-1 microphone, which accurately copies the position of the sound level meter, but also has a collar, even with the same focal length.

At the end of this chapter, it should be noted that measurements of noise and frequency response of sound will be performed on most cards only in load tests, as out of load and at lower load (including video decoding) operation is usually passive with fans turned off. On the other hand, we must also be prepared for exceptions with active operation in idle or graphics cards with dual BIOS setup, from which the more powerful one never turns off the fans and they run at least at minimum speed. Finally, as with measuring the noise level in one of the tests, we also record the frequency response of whining coils. But don’t expect any dramatic differences here. It will usually be one frequency, and the goal is rather to detect any potential anomalies. The sound of the whining coils is of course variable, depending on the scene, but we always measure in the same scene (in CS:GO@1080p).

Methodology: heat tests

We will also bring you heat tests, too. You are at HWCooling after all. However, in order to make it sensible at all to monitor temperatures on critical components not only of the graphics card, but anything in the computer, it is important to simulate a real computer case environment with healthy air circulation. The overall behavior of the graphics card as such then follows from this. In many cases, an open bench-table is inappropriate and results can be distorted. Therefore, during all, not only heat tests, but also measurement of consumption or course of graphics core frequencies, we use a wind tunnel with equilibrium flow.

Two Noctua NF-S12A fans are at the inlet and the same number is on the exhaust. When testing different system cooling configurations, this proved to be the most effective solution. The fans are always set to 5 V and the speed corresponds to approx. 550 rpm. The stability of the inlet air is properly controlled during the tests, the temperature being between 21 and 21.3 °C at a humidity of ±40%.

We read the heat from the internal sensors via GPU-Z. This small, single-purpose application also allows you to record samples from sensors in a table. From the table, it is then easy to create line graphs with waveforms or the average value into bar graphs. We will not use the thermal camera very much here, as most graphics cards have a backplate, which makes it impossible to measure the PCB heating. The key for the heating graphs will be the temperature reading by internal sensors, according to which, after all, the GPU frequency control also takes place. It will always be the heating of the graphics core, and if the sensors are also on VRAM and VRM, we will extract these values into the article as well.

Test rig

RAM Patriot Blackout (4× 8 GB, 3600 MHz/CL18)

2× SSD Patriot Viper VPN100 (512 GB + 2 TB)

Power supply BeQuiet! Dark Power Pro 12 1200 W


Test configuration
Processor	AMD Ryzen 9 5900X
CPU Cooler	Noctua NH-U14S@12 V s NT-H2
Motherboard	MSI MEG X570 Ace
Memory (RAM)	Patriot Blackout, 4× 8 GB, 3600 MHz/CL18
SSD	2× Patriot Viper VPN100 (512 GB + 2 TB)
PSU	BeQuiet! Dark Power Pro 12 (1200 W)

/* Here you can add custom CSS for the current table */ /* Lean more about CSS: https://en.wikipedia.org/wiki/Cascading_Style_Sheets */ /* To prevent the use of styles to other tables use "#supsystic-table-979" as a base selector for example: #supsystic-table-979 { ... } #supsystic-table-979 tbody { ... } #supsystic-table-979 tbody tr { ... } */

Note.: At the time of testing, graphics drivers Nvidia GeForce Game Ready 461.09 and AMD Adrenalin 20.12.2 are used, and the OS Windows 10 Enterprise build is 19042.

ComputeBench 2.0 (OpenCL)

Test platform benchmark; API OpenCL; no extra settings.

Game Effects

Advanced Compute

High Quality Computer Generated Imagery and Rendering

Computer Vision

ComputeBench 2.0 (CUDA)

Test platform benchmark; API Nvidia CUDA; no extra settings.

Game Effects

Advanced Compute

High Quality Computer Generated Imagery and Rendering

Computer Vision

SPECviewperf 2020

Test platform benchmark; API OpenGL and DirectX; no extra settings.

SPECworkstation 3

FLOPS, IOPS and memory speed tests

Test platform benchmark; app version 6.32.5600; no extra settings.

LuxMark

Test platform benchmark; API OpenCL; no extra settings.

Blender@Cycles

Test platform render BMW and Classroom; renderer Cycles, 12 tiles; extra settings are OpenCL for Radeon and CUDA for GeForce. The way most people will use it. OpenCL with GeForce is always slow because path tracing does not support GPU acceleration and is computed by the CPU. Nvidia OptiX is tested separately on supported cards (GeForce RTX) and the results are plotted in a separate graph.

Na grafických kartách GeForce RTX testujeme aj Nvidia OptiX

Blender@Radeon ProRender

Test platform render BMW and Classroom; renderer Radeon ProRender, 1024 samples; no extra settings. Extra settings are OpenCL for Radeon and CUDA for GeForce. Nvidia OptiX is tested separately on supported cards (GeForce RTX) and the results are plotted in a separate graph.

Blender@Eevee

Test platform animation renderEmber Forest; renderer Eevee, 350 images; extra settings are OpenCL for Radeon and CUDA for GeForce. Nvidia OptiX is tested separately on supported cards (GeForce RTX) and the results are plotted in a separate graph.

Photo editing

Adobe Photoshop and Affinity Photo: Test platform custom photo resolution 62 Mpx; no extra settings.

Adobe Photoshop graph, Field blur, avg. fps – higher is better
Affinity Photo graph, Gaussian blur, avg. fps – higher is better

Adobe Lightroom: Test platform custom 1-gigabyte archive of 42 raw photos (CR2) from DSLR; no extra settings.

Broadcasting

OBS Studio and XSplit: Test platform F1 2020 game benchmark; extra settings are allowed encoders AMD VCE/Nvidia Nvenc (AVC/H.264), output resolution 2560 × 1440 px (60 fps), target bitrate 19,700 kbps.

Password cracking

Test platform Hashcat; no extra settings. You can easily try the tests yourself. Just download the binary and enter the cipher you are interested in using the numeric code on the command line.

GPU clock speed

GPU and VRAM heating

VRAM heating

Net graphics power draw

Graph Graphics avg. power consumption [W] in 20 mbps VP9 movie
Graph Graphics avg. power consumption [W] in accelerated Google Chrome

VRAM clock increase record with connection of a second monitor

Analysis of 12 V subcircuit power supply

Analysis of 3.3 V subcircuit power supply

Noise level

Frequency response of sound

Measurements are performed in the TrueRTA application, which records sound in a range of 240 frequencies in the recorded range of 20–20,000 Hz. For the possibility of comparison across articles, we export the dominant frequency from the low (20–200 Hz), medium (201–2000 Hz) and high (2001–20,000 Hz) range to standard bar graphs. However, for an even more detailed analysis of the sound expression, it is important to perceive the overall shape of the graph and the intensity of all frequencies/tones.

Conclusion

The choice of tests for the second part was half fight with licenses and half with AMD optimizations. The aim, of course, was to choose tests so that there was a meaningful comparison across the competing cards. This is a relatively difficult task due to the fact that GeForce supports the progressive frameworks CUDA and OptiX. In addition, Radeon often gets the shorter end of the stick even under OpenCL. Not only in performance (as evidenced by the weaker results of LuxCoreRender/LuxMark), but also, for example, (no longer) supported Folding@home. Where OpenCL works well (and this behavior is also represented in our Blender tests), the analysis and results of the RX 6800 XT are remarkable.

With the Cycles renderer, the RX 6800 XT is significantly slower than the RTX 3080 with CUDA, but there’s also the 90-watt energy savings in AMD’s favor. The efficiency, at least with the current version of Blender (2.92) with the implementation of Intel Embree in Cycles, is at least remarkable. Thus, even though the RTX 3080 still has the upper hand, significantly in terms of performance and also is a hair better at efficiency (power per watt). With OptiX, of course, the gap in favor of Nvidia is getting bigger. The RX 6800 XT delivers better results with the Radeon Pro Render, but this was to be expected and there is probably no special reason why GeForce owners should worry. With the Eevee, the RTX 3080 is significantly/70% faster. However, it does not benefit from OptiX, quite the contrary – we’ve even seen a slight performance decrease. A similar statement is made for AMD SAM. You also don’t usually improve the results with it, and most of the time, with it being turned on, it’s a performance decrease without any additional benefits. This is true across all non-gaming tests, not just 3D rendering. So at business use, it is almost always better to turn it off.

If Radeon delivers a really attractive performance somewhere, it’s broadcasting. The RX 6800 XT’s decrease in fps in OBS compared to the RTX 3080 is one third. In Xsplit, the situation settles (so a nice comparison across applications came out of it), but it should be noted that OBS (unlike Xsplit) can be fully used in the free version. We recommend that Xsplit users turn off SAM, which has a dramatic impact on recording performance. Although it increases the game’s fps, the end result is dramatically lower encoding performance. The RTX 3080 dominates in hashing, but it should be noted that with some ciphers (SHA1/SHA2-256) the RX 6800 XT will handle better. However, Nvidia never has a big shortage, but at the same time, it can really impress, whether in AES-256 or when cracking the NTLMv2. network protocol.

The RTX 3080, i.e. Asus TUF RTX 3080 O10G Gaming (although it will probably not be very different from card to card) is more energy-saving when playing multimedia (tested on H.265/HEVC video) or after connecting a second monitor with high resolution. With it, the power draw on all graphics cards always increases, but in the case of the RX 6800 XT it is very significant compared to the state with a single monitor. In terms of idle, it’s more than 5 times (7.5 vs. 41 W). This is due to the transition from minimum to maximum VRAM clock speed. For lower resolution monitors (up to 2x QHD@60 Hz), this may not bother you because the memory remains underclocked. With the RTX 3080, the increase in power consumption after connecting a second monitor is minimal (from 22 to 27 W), but again, compared to the RX 6800 XT, the initial power consumption with a single monitor is relatively high.

Continue: Analysis of 3.3 V subcircuit power supply