HEVC Benchmark

Howard-Vigorita wrote on 5/24/2020, 3:12 AM

(continuing the older benchmark roundup thread)

Just got around to benchmarking Vegas 17 build 421 on my workstations and came up with a 4k HEVC variation on the original Red Car benchmark. Here's a comparative summary of stats for my i9-9900k/Radeon 7 machine:

What I did was take the original Red Car project, unchanged, except for media substitution. I transcoded the original Mercedes clip #2 to HEVC. For clips #1 and #3 I swapped in some HEVC footage of my back yard taken with a zCam E2 adding a Camera and grading LUT as a media fx. In addition to render timing, I also noted the ability to play the HEVC project with proxies as well as the ability to play the zCam footage+LUT alone without proxies, listing the maximum preview quality with no drop in frame rate.

The html version of the above table also includes my xeon/RX-580 machine which I plan on updating with stats from some of my other machines when I get a chance.

I've put a zip with all the files in it on a google drive here if anyone wants to report numbers for their systems... I'm particularly curious how some of the Nvidia boards compare.

Comments

Howard-Vigorita wrote on 5/25/2020, 12:03 AM

Updated with comparative results from an Intel NUC as well as results from an AMD RX-5700xt Navi board which I just installed in my xeon system to replace an aging RX-580. The numbers indicate the Navi board bumps up performance about 10% over the RX-580 on VCE rendering. Decoding seems a little faster although display performance might be a tad less. One interesting contrast jumps out, however. Performance on the Sample Project benchmark jumps dramatically... I'll get into the weeds on that over on the rx-5700xt thread.

Here are the numbers for my xeon system with the RX-580 in it...

And here are the numbers for the Navi board in the same system...

I'll also update the html online version for easier comparisons with the Radeon VII numbers.

Reyfox wrote on 5/30/2020, 7:19 AM

I have been considering a 5700series card to replace my very old RX480 8GB. A card that has been reliable and consistent with no problems or issues with VP.

But now with "Big Navi" on it's way, I'll wait a few and see what that brings.

Thanks for the information.

Howard-Vigorita wrote on 5/30/2020, 10:57 AM

I have an older win7-64 system with an rx480 in it but it's the older 4gb version. I'm going to take a shot at moving the Navi to that. If it'll fit and run I'll bench it. Waiting on a used Vega64 board I located to put in the Xeon so I'm going to try that there for now. It's a Sapphire Nitro+ Vega64 with a 3-fan setup identical to their Navi board. Runs at a higher clock so I'm hoping it'll match or perhaps exceed the hevc performance of the Radeon 7 in my newest system.

Reyfox wrote on 5/30/2020, 2:39 PM

Interested in those benchmarks when you run them. Curious to see how much of a difference there is.

Howard-Vigorita wrote on 6/3/2020, 4:14 AM

Was updating my Asus motherboard drivers today and the driver for the Intel HD630 igpu made a tremendous difference processing h.265 clips on the timeline rendering with Vegas 17 build 452. But only after I unchecked "Enable legacy HEVC decoding via Intel QSV" in the File I/O preferences tab. Render time of an HEVC benchmark dropped from 93 seconds down to 29 seconds. The updated Intel driver version is 26.20.100.8141.

Howard-Vigorita wrote on 6/12/2020, 2:34 PM

Sorry this took so long but the new Intel and Amd drivers changed the picture so much I decided to rerun all the Vegas 17 build 452 benchmarks over again to insure that the numbers are apples to apples. The Amd drivers are all 20.5.1 Adrenelin2020 throughout. They provide better and more stable performance even though I just hate the new interface. The new Intel drivers are totally different. There seems to be a paradigm shift away from hardware encoding to the hardware being more dedicated to decoding. This is reflected in earlier runs I did with build 452 before updating yielding qsv render times slightly faster than vce while decoding times were similar. Since the Intel driver update, qsv render times are longer, in some cases similar to Mainconcept, while decode times are substantially better. I'm guessing they've channeled encoding chores to a cpu-driven runtime to free up hardware for decoding. Probably a good move since folks here didn't seem to think much of qsv render quality anyway... wonder if its better now. This opens the interesting possibility of trying one of the coming Intel Xe pcie boards to give a decoding boost to systems that do not have a resident Intel igpu. Based on my new numbers, I've shifted all my test renders from qsv to vce and set File I/O decode in Vegas 17 to Intel.

fifonik wrote on 6/12/2020, 6:05 PM

The Amd drivers are all 20.5.1 Adrenelin2020 throughout. They provide better and more stable performance even though I just hate the new interface.

Could you advise, what was the previous AMD driver version you used?

Howard-Vigorita wrote on 6/12/2020, 10:15 PM

@fifonik I was using the Pro Enterprise Drivers 2020q2 which I think were showing up as 20.0.4 or something like that but kept recommending update to 20.4.1 with 20.5.1 optional. Not sure amd's Enterprise thing is quite ready for prime time yet.

Howard-Vigorita wrote on 8/7/2020, 6:23 AM

Ran the benchmark gamut on my 9900k - Radeon 7 system with Vegas 18 build 284 and renders were generally a bit faster. I ran the 4K Sample Project benchmark as well as the original Red Car, the 4k AVC Red Car, and the 4K HEVC Red Car. I also compared results using both Intel and AMD decoding. Numbers are on-line here: http://www.rtpress.com/roundup2020.htm

One came up slower for v18: the original Red Car... 14 sec compared to 12 sec with v17. One rendering combo crashed my v18 system every time I tried it, however: the HEVC Red Car project rendered to an Intel QSV 4k mp4.

Also threw together some little charts comparing AMD VCE for both versions with AMD doing both encoding and decoding vrs AMD encoding with Intel decoding.... I get slightly better results using both together on h.264 avc clips on the timeline but the improvement becomes dramatic with h.265 hevc source clips.

Here's a comparison chart for rendering to 1080p:

And another chart for rendering to 2160p...

Former user wrote on 8/7/2020, 7:19 AM

What does 4K HEVC decode look like on AMD, is it 100%. Do you think it's the problem of AMD decoder(hardware) or problem with VP's implementation of decoder?

Howard-Vigorita wrote on 8/7/2020, 12:29 PM

I think it's both. One thing I noticed when my HVEC render with qsv crashed (with io set to decode with amd) was that both the amd and intel gpus were showing decode activity at the same time. That can't be right. Tried to capture it but Vegas keeps shutting off amd Relive when it starts doing that. The render crash also corrupted Vegas's own capture facility (even though it shows as a separate Vegas instance) so that couldn't do it either. Might have to just aim a camera at the screen and capture the crash that way. Or maybe try to capture an rconsole screen to a different computer. But I think I'll also try a little capturing of renders that don't crash for a look see.

Howard-Vigorita wrote on 8/7/2020, 12:47 PM

Another issue that I haven't really dug deeply into yet is that both v17 and v18 seem to have a stability issue handling a 4k hvec project without proxies. The horsepower is there for playback, editing, and rendering but both versions lock up after a short while doing heavy editing that involves repeated playback of small sections. Happened when I was doing audio track envelope editing with the 4k hvec video track just there for visual reference. Seems to happen after 5 or 6 edits. I was able to soldier on with lots of ctrl-s saves and get it done in spite of that. I think using proxies would probably avert the problem but I was hoping to avoid having to do that. Oddly, once I was done with the audio part things went much more smoothly through the color grading. Also had a temporary problem during final rendering that went away once I cleaned out the Vegas temp directory... might have been caused by thumbnails being turned on when I 1st installed v18 which I didn't notice until after I dropped 20 1-minute clips onto the timeline. Parallel project in v17 with thumbnails turned off did not have that problem.