View Full Version : Which processor to encode x265 4K ?
Pages :
[
1]
2
3
4
5
6
7
8
Nico8583
24th June 2019, 21:15
Hi :)
I would like to change my old X6 1090T to encode x265 1080p/4K.
I know Ryzen 3 will be out soon but I don't know if it would be a good value for money choice.
Currently, which processors are good value for money ? Ryzen 7 2700x ? i7 9700k ?
Thank you !
Groucho2004
24th June 2019, 21:43
Have a look here (https://www.techpowerup.com/review/intel-core-i7-9700k/6.html) (scroll down to "H.265 Media Encoding").
mariush
24th June 2019, 22:08
For comparison, your x6 1090t is somewhere around i3-7100 .. Ryzen 3 1200 in those charts on Techpowerup.
Nico8583
24th June 2019, 22:13
Thank you, i7 9700k and R7 2700X seem to be very close in performances.
i7 is much expensive and need a CPU cooler but 2700x need a graphic card.
Nico8583
24th June 2019, 22:20
Thank you for comparison, so I can expect FPS x 4 with 9700k or 2700X
RanmaCanada
24th June 2019, 23:00
I would say wait and see what happens with Ryzen 3000 series after they are released. You've waited this long to upgrade, so seriously, what's another 2-3 weeks (for PROPER reviews). It is highly possible that with their increased IPC that they might catch Intel for x265. And if not, well the Ryzen 2000 series will be a LOT cheaper by then, as AMD does whatever they can to get rid of old stock, where as Intel likes to keep prices on old stock stupidly high.
Asmodian
25th June 2019, 01:17
Actually Intel is expected to reduce the prices of their CPUs by up to 15%. Zen2 is too good for them to ignore this time.
It really is not the right time to get a CPU, 2-3 weeks should offer better CPUs per dollar from both AMD and Intel.
Nico8583
25th June 2019, 07:26
Yes, you're right both, I'll not buy anything before 2 weeks, but I start to search an alternative if Ryzen 3 are not as good as expected ;) (because if there are discount prices after Ryzen 3 release, I wish to buy immediatly and not thinking if it is a good choice). Now I know 9700K and 2700X are good values.
Thank you !
hajj_3
25th June 2019, 08:26
zen 2 supports proper 256bit avx 2 like intel, zen 1 used 2 x 128bit. 256bit AVX2 support increases performance of x265 by quite a bit, maybe 10% or something so i wouldn't buy zen+ if you are going to be doing quite a bit of x265 encoding.
Atak_Snajpera
25th June 2019, 11:45
Yes, you're right both, I'll not buy anything before 2 weeks, but I start to search an alternative if Ryzen 3 are not as good as expected ;) (because if there are discount prices after Ryzen 3 release, I wish to buy immediatly and not thinking if it is a good choice). Now I know 9700K and 2700X are good values.
Thank you !
Zen2 will be much faster than Zen1 due to AVX256! x265 really loves AVX256. That's the main reason why 10C 4GHz Intel is only slightly slower than ThreadRipper 1950x@4GHz.
2990WX has very low fps because of broken windows scheduler.
Just compare those results.
65.0 fps - 2 x Intel Xeon E5-4660 v3 @ 2.9GHz^ ( 14C / 28T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
63.6 fps - Intel Core i9-7920X @ 4.6GHz^ ( 12C / 24T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
54.3 fps - Intel Core i9-7900X @ 4.7GHz^ ( 10C / 20T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
52.5 fps - AMD Threadripper 2990WX @ 3.4GHz ( 32C / 64T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
50.3 fps - AMD Threadripper 1950X @ 4.0GHz^ ( 16C / 32T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
44.6 fps - Intel Core i9-7900X @ 4.0GHz ( 10C / 20T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
43.6 fps - AMD Threadripper 1950X @ 3.4GHz ( 16C / 32T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
36.8 fps - Intel Core i7-8700K @ 5.0GHz^ ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
35.3 fps - Intel Core i7-8700K @ 4.9GHz^ ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
33.9 fps - Intel Core i7-5960X @ 4.4GHz^ ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
31.8 fps - Intel Core i7-8700K @ 4.3GHz ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
29.8 fps - Intel Xeon E5-2675 v3 @ 1.8GHz ( 16C / 32T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
25.5 fps - AMD Ryzen 7 1700 @ 3.7GHz^ ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
24.8 fps - Intel Core i7-6700K @ 4.8GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
24.3 fps - AMD Ryzen 7 1700 @ 3.5GHz^ ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
23.8 fps - Intel Core i5-8400 @ 3.8GHz ( 6C / 6T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
23.7 fps - Intel Core i7-7700K @ 4.8GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
23.3 fps - Intel Core i7-6700K @ 4.7GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
22.6 fps - Intel Core i7-6700K @ 4.5GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
21.6 fps - Intel Core i7-7700K @ 4.4GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
20.6 fps - AMD Ryzen 5 1600 @ 3.8GHz^ ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
18.6 fps - Intel Core i7-6600K @ 4.5GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
16.4 fps - Intel Xeon E5-2690 @ 2.9GHz ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
15.8 fps - Intel i7-6770HQ @ 2.6GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
15.8 fps - Intel Core i5-4690K @ 4.2GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
15.6 fps - Intel Xeon E3 1231 v3 @ 3.4GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
14.7 fps - Intel Xeon E5-2670 @ 2.6GHz ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
14.7 fps - Intel Core i7-3930K @ 3.2GHz ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
14.6 fps - AMD Ryzen 5 2400G @ 4.0GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.9 fps - Intel Core i5-7400 @ 3.5GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.8 fps - Intel Core i5-6500 @ 3.2GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.5 fps - AMD Ryzen 5 1500X @ 3.5GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.3 fps - Intel Core i5-4570S @ 3.6GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
12.7 fps - 2 x Intel Xeon X5550 @ 3.0GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
12.4 fps - AMD Ryzen 5 2200G @ 4.0GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
12.1 fps - AMD FX-8320 Eight-Core @ 4.32GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
12.0 fps - Intel Core i5-4460 @ 3.2GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
11.2 fps - Intel Core i7-3770K @ 3.5GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
9.7 fps - Intel Core i3-7100 @ 3.9GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
8.8 fps - AMD Ryzen 3 1300X @ 3.5GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
8.3 fps - Intel Core i5-2400 @ 3.7GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
7.8 fps - Intel i7-3612QM @ 2.1GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
7.6 fps - Intel Core i7-7500U @ 3.5GHz^ ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
6.1 fps - Intel Celeron G3900 @ 4.0GHz^ ( 2C / 2T ) MMX2 SSE2Fast SSSE3 SSE4.2 LZCNT
5.9 fps - AMD Athlon X4 760K Quad Core @ 4.5GHz^ ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
5.6 fps - Intel Pentium G3258 @ 4.2GHz^ ( 2C / 2T ) MMX2 SSE2Fast SSSE3 SSE4.2 LZCNT
5.5 fps - Intel Xeon X5470 @ 3.33GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
4.8 fps - Intel Core i3-3220 @ 3.3GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
4.4 fps - Intel Core2 Quad Q8200 @ 2.8GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
4.2 fps - Intel Core i3-2100 @ 3.1GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
3.7 fps - Intel Core2 Quad Q8200 @ 2.33GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
3.6 fps - Intel Core i3-4005U @ 1.7GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
1.9 fps - AMD Athlon II X4 620 @ 2.6GHz ( 4C / 4T ) MMX2 SSE2Fast LZCNT
Nico8583
25th June 2019, 12:52
Thank you !
So the best way to encode x265 is Ryzen 3000 or i7 8700K/9700K(/i9 9900K but too much expensive) ?
Atak_Snajpera
25th June 2019, 13:30
Thank you !
So the best way to encode x265 is Ryzen 3000 or i7 8700K/9700K(/i9 9900K but too much expensive) ?
It is just a matter of your budget. Ryzen 3600 looks good if you OC to 4.5GHz.
benwaggoner
25th June 2019, 14:47
It is just a matter of your budget. Ryzen 3600 looks good if you OC to 4.5GHz.
Also, doesn't AVX512 help performance with slower presets at 4K resolutions? Optimum processor might differ some based on preset.
Operating costs also factor in, ala pixels per picojoule.
Atak_Snajpera
25th June 2019, 15:26
Also, doesn't AVX512 help performance with slower presets at 4K resolutions? Optimum processor might differ some based on preset.
Operating costs also factor in, ala pixels per picojoule.
Have you seen 9900k with AVX-512 support recently?
Asmodian
25th June 2019, 21:14
The i9-9900X supports AVX-512 (https://ark.intel.com/content/www/us/en/ark/products/189124/intel-core-i9-9900x-x-series-processor-19-25m-cache-up-to-4-50-ghz.html), not the k. :p
It is odd that list of benchmarks isn't using AVX-512 on the i9-7900X or anything else, it would be nice to know how much impact it has.
benwaggoner
25th June 2019, 22:19
The i9-9900X supports AVX-512 (https://ark.intel.com/content/www/us/en/ark/products/189124/intel-core-i9-9900x-x-series-processor-19-25m-cache-up-to-4-50-ghz.html), not the k. :p
It is odd that list of benchmarks isn't using AVX-512 on the i9-7900X or anything else, it would be nice to know how much impact it has.
I'm not sure. Perhaps because avx512 needs to be explicitly turned on?
I've got my dual Xeon 6140 workstation coming next week (basically a physical EC2 c5.16xlarge), and I can do some benchmarks when it arrives.
And I've got some 8K test sources too, so I can benchmark those with/without. I would expect that the value may go up with resolution, as avx512 is only supposed to become useful at 2160p.
Blue_MiSfit
26th June 2019, 03:40
I've got my dual Xeon 6140 workstation coming next week (basically a physical EC2 c5.16xlarge), and I can do some benchmarks when it arrives.
drool...
Asilurr
26th June 2019, 04:12
Just compare those results.
[...]I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology. Did they use the same hardware reference frame (same memory modules, same SSD)? Did they use the same software version (and contemporary versions of x265 too, not [e.g.] two years old ones)? Did they use the same parameter configuration? Did they use the same content source? Did they test multiple scenarios (i.e. various bit depths, various chroma subsampling types, various resolutions)? Did they use an OS which allows meaningful comparison of highly-threaded CPUs (not repeating the unfortunate case of Threadrippers on Windows)?
Atak_Snajpera
26th June 2019, 09:58
I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology. Did they use the same hardware reference frame (same memory modules, same SSD)? Did they use the same software version (and contemporary versions of x265 too, not [e.g.] two years old ones)? Did they use the same parameter configuration? Did they use the same content source? Did they test multiple scenarios (i.e. various bit depths, various chroma subsampling types, various resolutions)? Did they use an OS which allows meaningful comparison of highly-threaded CPUs (not repeating the unfortunate case of Threadrippers on Windows)?
Oh boy! You and your questions...
Dude! Those results come from my benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/
NikosD
26th June 2019, 12:14
Ryzen 3000 will have no clock penalty (aka no performance penalty) leveraging AVX2 instructions according to AMD.
So, it's possible Ryzen 3000 to be a lot faster with heavy use of AVX2 compared to all Intel processors so far, due to no clock restrictions.
excellentswordfight
26th June 2019, 18:03
I'm not sure. Perhaps because avx512 needs to be explicitly turned on?
I've got my dual Xeon 6140 workstation coming next week (basically a physical EC2 c5.16xlarge), and I can do some benchmarks when it arrives.
And I've got some 8K test sources too, so I can benchmark those with/without. I would expect that the value may go up with resolution, as avx512 is only supposed to become useful at 2160p.
I’ve done some tests at 2160p with a few skylake-sp platforms. Even at 2160p i had a hard time getting the same utilization as without avx512, and even without that it’s hard to see any big gains cause of the ~500Mhz clockspeed penalty.
RanmaCanada
27th June 2019, 02:31
Oh boy! You and your questions...
Dude! Those results come from my benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/
It's obvious some people don't do their "research" before they post :D
I did something similar to The Stilt, when he was wrong and just called him a random haha.
Thanks for posting everything in one place! It will make things far more easier to compare once we get some runs from Ryzen 2!
nevcairiel
27th June 2019, 10:52
some runs from Ryzen 2!
Since we're liking to be accurate:
Its either Zen 2, or Ryzen 3000. Ryzen 2 is misleading, and not a term used by AMD, since Ryzen 3/5/7/9 are model-classes in their lineup, so it could easily be mistaken for a lower-end model - and next generation there would be even more real confusion. :)
Asilurr
27th June 2019, 14:52
Dude! Those results come from my benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/The link you've provided redirects to Mediafire (http://www.mediafire.com/file/nm5n7xg2nb22zl7/x265_FHD_Benchmark.7z), where one can download the presumably latest version (?) of the benchmark. Id est the package uploaded on July 26th, 2018. Inside the package, one can find:
1. An old version of x265 [2.2+15-a18ab7656c30].
2. An old version of FFmpeg [N-82889-g54931fd].
3. The five test sources, which are all 8-bit, all 4:2:0, all 16:9 1080p.
As for the benchmark itself:
1. As one can't test a given CPU in vacuo, one actually tests an ensemble of CPU+MB+RAM+IO. Rephrasing: one adds degrees of freedom to the system, together those serve the purpose of propagating the uncertainty.
2. As one doesn't test x265 on its own, due to the way the benchmark is designed, one actually tests the pair of FFmpeg+x265. Another degree of freedom, another potential path for the propagation of uncertainty.
3. As the benchmark uses an old version of x265, all the results which are obtained are actually "watermarked" by the common reference frame of a 2.2 x265 encoder. One can't extrapolate the results to a 3.1 x265 encoder, and assume them to hold true by default.
4. As the benchmark tests the default configuration of parameters for x265 (i.e. --preset medium), all the results which are obtained are actually "watermarked" by the common reference frame of that particular preset. One can't extrapolate the results to another preset (or another parameter configuration), and assume them to hold true by default.
5. The benchmark doesn't test a single low complexity source, or a single 10-bit source, or a single non-4:2:0 source, or a single non-FHD source. All the results are again "watermarked" by a highly specific encoding scenario. One can't extrapolate them to another encoding scenario, and assume them to hold true by default.
Do you understand what is the actual result of the benchmark you are providing? It enables one to say: I am encoding this particular source of this particular complexity (at this particular resolution, this particular bit depth, this particular chroma subsampling), within this particular software environment (OS, x265, FFmpeg), on this particular machine (CPU, MB, RAM, IO). It certainly does not enable one to say: CPU MMM achieves an average of abc% better FPS than CPU NNN, across all possible/conceivable encoding scenarios.
At this point, I'd simply reiterate my initial statement: I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology.
Atak_Snajpera
27th June 2019, 16:03
The link you've provided redirects to Mediafire (http://www.mediafire.com/file/nm5n7xg2nb22zl7/x265_FHD_Benchmark.7z), where one can download the presumably latest version (?) of the benchmark. Id est the package uploaded on July 26th, 2018. Inside the package, one can find:
1. An old version of x265 [2.2+15-a18ab7656c30].
2. An old version of FFmpeg [N-82889-g54931fd].
3. The five test sources, which are all 8-bit, all 4:2:0, all 16:9 1080p.
As for the benchmark itself:
1. As one can't test a given CPU in vacuo, one actually tests an ensemble of CPU+MB+RAM+IO. Rephrasing: one adds degrees of freedom to the system, together those serve the purpose of propagating the uncertainty.
2. As one doesn't test x265 on its own, due to the way the benchmark is designed, one actually tests the pair of FFmpeg+x265. Another degree of freedom, another potential path for the propagation of uncertainty.
3. As the benchmark uses an old version of x265, all the results which are obtained are actually "watermarked" by the common reference frame of a 2.2 x265 encoder. One can't extrapolate the results to a 3.1 x265 encoder, and assume them to hold true by default.
4. As the benchmark tests the default configuration of parameters for x265 (i.e. --preset medium), all the results which are obtained are actually "watermarked" by the common reference frame of that particular preset. One can't extrapolate the results to another preset (or another parameter configuration), and assume them to hold true by default.
5. The benchmark doesn't test a single low complexity source, or a single 10-bit source, or a single non-4:2:0 source, or a single non-FHD source. All the results are again "watermarked" by a highly specific encoding scenario. One can't extrapolate them to another encoding scenario, and assume them to hold true by default.
Do you understand what is the actual result of the benchmark you are providing? It enables one to say: I am encoding this particular source of this particular complexity (at this particular resolution, this particular bit depth, this particular chroma subsampling), within this particular software environment (OS, x265, FFmpeg), on this particular machine (CPU, MB, RAM, IO). It certainly does not enable one to say: CPU MMM achieves an average of abc% better FPS than CPU NNN, across all possible/conceivable encoding scenarios.
At this point, I'd simply reiterate my initial statement: I would advise a healthy dose of skepticism whenever you see results without extensive coverage of the testing methodology.
Are you trying to convince me that AMD's AVX128 in Zen1 is able to compete with full fat Intel's AVX256. x256 is highly optimized for AVX2 and that's why ZEN1 sucks in this encoder. Period! Luckily Zen2 finally has AVX256 so I'm expecting 3600 to have similar performance as stock 8700k.
BTW. Your requirements for "proper" benchmark are just insane and totally unrealistic! I advise you to stop using any software because there are countless variables affecting performance of your machine (including phases of the moon).
Asilurr
28th June 2019, 06:01
You're being deliberately obtuse, I suppose I can attempt a simplistic analogy by referring to a system with only two degrees of freedom.
I want to investigate what happens to water when I heat it up. To be rigorous, that's the so-called "pure water" which is known today as UPW (https://en.wikipedia.org/wiki/Ultrapure_water). At a pressure of 1 atm, I observe that water is gaseous at 400 K. Conducting a second experiment, I observe that water is gaseous at 500 K too. At this point I ask myself: can I consider the previous results a good predictor of what would happen to water when it's heated to 600 K instead? Can I simply assume that it would be gaseous, thus not having to actually perform a test? The answer to that is no, a proper phase diagram (https://upload.wikimedia.org/wikipedia/commons/0/08/Phase_diagram_of_water.svg) shows what happens to water heated at 600 K and highlights the critical importance of the other parameter of this simplistic system.
To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here (http://forum.doom9.org/showthread.php?p=1877898#post1877898)) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s).
NikosD
28th June 2019, 11:24
To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here (http://forum.doom9.org/showthread.php?p=1877898#post1877898)) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s). Hello.
Could you propose an existent benchmark, covering your needs of proper x265 encoding benchmarking procedure for multithreaded CPUs ?
Or do you have a suggestion how to build one ?
Atak_Snajpera
28th June 2019, 11:57
You're being deliberately obtuse, I suppose I can attempt a simplistic analogy by referring to a system with only two degrees of freedom.
I want to investigate what happens to water when I heat it up. To be rigorous, that's the so-called "pure water" which is known today as UPW (https://en.wikipedia.org/wiki/Ultrapure_water). At a pressure of 1 atm, I observe that water is gaseous at 400 K. Conducting a second experiment, I observe that water is gaseous at 500 K too. At this point I ask myself: can I consider the previous results a good predictor of what would happen to water when it's heated to 600 K instead? Can I simply assume that it would be gaseous, thus not having to actually perform a test? The answer to that is no, a proper phase diagram (https://upload.wikimedia.org/wikipedia/commons/0/08/Phase_diagram_of_water.svg) shows what happens to water heated at 600 K and highlights the critical importance of the other parameter of this simplistic system.
To return to the discussion of benchmarking encoding times, we're now looking at a system with dozens of degrees of freedom: the parametric space of the hardware, the parametric space of the software, the parametric space of the source to be encoded, the parametric space of the encoding process itself. This entire thread was initiated by explicitly mentioning UHD/4K encoding scenarios. It's right in front of your eyes, mentioned both in the title and the leading post. To which you've replied (here (http://forum.doom9.org/showthread.php?p=1877898#post1877898)) by implicitly assuming that the results of FHD benchmarking scenarios (highly specific FHD encoding scenarios, as already pointed out) will simply hold true even if one particular parameter varies drastically, claiming that increasing the resolution four times doesn't alter the expected result. To which I replied that an implicit assumption is not sound, as there is an explicit need of additional testing to account for the variable parameter(s).
Yes! You can easily extrapolate results from 1920x1080 to 3840x2160. Encoding speed will drop 4 times. 4x more pixels to examine means 4 times more cpu cycles has to be used. End of story. I'm done with you!
RanmaCanada
29th June 2019, 04:31
Since we're liking to be accurate:
Its either Zen 2, or Ryzen 3000. Ryzen 2 is misleading, and not a term used by AMD, since Ryzen 3/5/7/9 are model-classes in their lineup, so it could easily be mistaken for a lower-end model - and next generation there would be even more real confusion. :)
Ya got me there! and thank you.
Now hopefully someone will leak out something other than stupid geekbench results. I seriously want to see how well this generation will do in encoding. I don't care about games..I want encoding benchmarks.
Sadly, I think we are going to have to wait till one of the forum members gets one as we know review sites don't exactly know how to benchmark when it's not games.
benwaggoner
1st July 2019, 22:00
Yes! You can easily extrapolate results from 1920x1080 to 3840x2160. Encoding speed will drop 4 times. 4x more pixels to examine means 4 times more cpu cycles has to be used. End of story.
Not entirely. CABAC can take up a decent chunk of CPU, and since bitrate isn't linear to pixel count, in the real world you get less than a 4x increase for 4x the pixels. Plus the more pixels there are, the less each one matters so some different encoding technique.
Changing resolution can also really impact threading; more pixels mean fewer frame threads are needed on smaller core counts, reducing overhead.
And of course, how well does encoding scale across multiple cores? Across the same or different NUMA nodes?
mandarinka
4th July 2019, 04:06
https://www.ptt.cc/bbs/PC_Shopping/M.1561539742.A.61C.html
This has a (unconfirmed) results for x265 benchmark used on HWBot. I think it has an older binary so gains from AVX256 might be a bit subdued, but the same would be true for the Intel chip.
The benchmark tests and reports max single thread turbo clock at initialization so I think the screenshot means that these are scores for stock Ryzen 5 3600 and Core i7-8700K.
Basically looks nice for Ryzen 3000 and I would wait for it and not get anything else, if this is confirmed.
Asmodian
4th July 2019, 04:28
Very nice results, I hope they are true! It is looking like they probably are, with more leaks from other areas (https://www.gamersnexus.net/news-pc/3485-hw-news-intel-asks-if-its-screwed-displayport-20-and-more).
Forteen88
4th July 2019, 08:22
https://www.ptt.cc/bbs/PC_Shopping/M.1561539742.A.61C.htmlUnfortunately, they don't give information about the speed of the RAM used.
mandarinka
5th July 2019, 22:29
https://imgur.com/a/YkoOCgM
Check that Handbrake result :) Pretty nice if correct.
Nico8583
6th July 2019, 11:19
Interesting :)
What is the difference between i9 9900K 95W and i9 9900K ? 95W is the stock TDP and both are 3,6Ghz. Perhaps the second is O/C ?
sneaker_ger
6th July 2019, 11:25
3.6 GHz is only the advertised base clock. The i9-9900K goes up to 5 GHz dynamically. If it's not limited to the default "95W" setting it can keep turbo clocks longer.
https://www.anandtech.com/show/13591/the-intel-core-i9-9900k-at-95w-fixing-the-power-for-sff
benwaggoner
6th July 2019, 20:59
Very nice results, I hope they are true! It is looking like they probably are, with more leaks from other areas (https://www.gamersnexus.net/news-pc/3485-hw-news-intel-asks-if-its-screwed-displayport-20-and-more).
It's be helpful if they documented what parameters were actually being tested. "1080p" is obviously not a x265 --preset.
hajj_3
6th July 2019, 21:37
It's be helpful if they documented what parameters were actually being tested. "1080p" is obviously not a x265 --preset.
Zen2 chips and the reviews are out tomorrow so not long until we have some good x265 and x264 benchmarks for zen2 to compare with latest intel chips.
hajj_3
7th July 2019, 14:19
x265 and x264 benchmarks of the new Ryzen 3000 series chips:
https://images.anandtech.com/graphs/graph14605/111203.png
https://images.anandtech.com/graphs/graph14605/111201.png
https://img.purch.com/r/711x457/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9VL04vODQ0Nzk5L29yaWdpbmFsL2ltYWdlMDEzLnBuZw==
https://img.purch.com/r/711x457/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9VL1AvODQ0ODAxL29yaWdpbmFsL2ltYWdlMDEyLnBuZw==
handbrake v1.2.2:
https://techreport.com/r.x/2019_07_06_AMD_s_Ryzen_7_3700X_and_Ryzen_9_3900X_CPUs_reviewed/Graphs_handbrake.png
https://hothardware.com/ContentImages/Article/2873/content/x265.png
staxrip x264 and x265 benchmarks: https://nl.hardware.info/reviews/9397/10/amd-ryzen-7-3700x-a-ryzen-9-3900x-review-intel-voorbij-benchmarks-video--en-audio-encoding-x264-x265-en-flac
birdie
7th July 2019, 15:11
The most relevant graph for encoding/rendering:
https://techreport.com/wp-content/uploads/2019/07/power-taskenergy-FIXED.png
Atak_Snajpera
7th July 2019, 16:24
https://p.xfastest.com/~sinchen/AMD-Ryzen-7-3700X-9-3900X/AMD-Ryzen-7-3700X-9-3900X-34.jpg
Boulder
7th July 2019, 18:08
Looks like a 3700X is the new 1700X as the best bang for buck. Hopefully we'll see a benchmark for the most used presets like slow, slower and veryslow.
We should really thank AMD for keeping the socket the same for all these years, upgrading gets very cheap.
hajj_3
7th July 2019, 18:12
Looks like a 3700X is the new 1700X as the best bang for buck. Hopefully we'll see a benchmark for the most used presets like slow, slower and veryslow.
We should really thank AMD for keeping the socket the same for all these years, upgrading gets very cheap.
3600 is the best bang for buck, 6 cores, 12 threads - $199. Those weren't given to reviewers though as AMD obviously wants people to buy their more expensive chips.
Stereodude
7th July 2019, 18:40
Do any of these sites run any sort of standardized x265 test that I can download and run on my system to see how my current system compares to the new Ryzen 3xxx CPUs?
Atak_Snajpera
7th July 2019, 18:56
Do any of these sites run any sort of standardized x265 test that I can download and run on my system to see how my current system compares to the new Ryzen 3xxx CPUs?
Guys from https://news.xfastest.com/review/review-02/66816/amd-ryzen-7-3700x-ryzen-9-3900x-review/
used my x265 fhd benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/
That guy also used the same benchmark but instead of fps showed elapsed time in seconds. To get fps you have to do this 2500/seconds.
https://youtu.be/rcFUGSElZEs?t=8m18s
Stereodude
7th July 2019, 19:34
Guys from https://news.xfastest.com/review/review-02/66816/amd-ryzen-7-3700x-ryzen-9-3900x-review/
used my x265 fhd benchmark
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/
That guy also used the same benchmark but instead of fps showed elapsed time in seconds. To get fps you have to do this 2500/seconds.
https://youtu.be/rcFUGSElZEs?t=8m18s
Thanks! Is the build of x265 in your package new enough to take advantage of all the new (to AMD) features in the Zen 2 architecture?
Intel Xeon E5-2687W v2 @ 3.4GHz ( 8C / 16T )
y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao
encoded 2500 frames in 131.23s (19.05 fps), 7025.74 kbps, Avg QP:37.21
So the Ryzen 3900X is ~3x as fast with x265 encoding as my Xeon E5-2687W v2? :confused:
I realize this is only one particular x265 test scenario, but if I can get a 3x speed improvement with the much slower preset I normally use for 1080p x265 I should be in the car heading to Microcenter to buy a Ryzen 3900X system right now.
Atak_Snajpera
7th July 2019, 19:44
Thanks! Is the build of x265 in your package new enough to take advantage of all the new (to AMD) features in the Zen 2 architecture?
Intel Xeon E5-2687W v2 @ 3.4GHz ( 8C / 16T )
y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 unknown frame count
raw [info]: output file: NUL
x265 [info]: HEVC encoder version 2.2+15-a18ab7656c30
x265 [info]: build info [Windows][GCC 6.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main Still Picture profile, Level-4.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 50 / 500 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-28.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao
encoded 2500 frames in 131.23s (19.05 fps), 7025.74 kbps, Avg QP:37.21
So the Ryzen 3900X is ~3x as fast with x265 encoding as my Xeon E5-2687W v2? :confused:
I realize this is only one particular x265 test scenario, but if I can get a 3x speed improvement with the much slower preset I normally use for 1080p x265 I should be in the car heading to Microcenter to buy a Ryzen 3900X system right now.
Ivybridge does not have AVX2 hence poor performance in x265.
Stereodude
7th July 2019, 20:08
Ivybridge does not have AVX2 hence poor performance in x265.
Well, the x264 results for the 3900X are almost double this system too and AFAIK AVX2 makes less of a difference with x264.
encoded 2500 frames, 38.21 fps, 22398.07 kb/s
benwaggoner
7th July 2019, 20:16
The most relevant graph for encoding/rendering:
https://techreport.com/r.x/2019_07_06_AMD_s_Ryzen_7_3700X_and_Ryzen_9_3900X_CPUs_reviewed/power-taskenergy-FIXED.png
The picture's URL is 404.
Stereodude
7th July 2019, 20:18
The picture's URL is 404.
Works here.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.