x265 Ryzen discussion [Archive]

birdie

2nd March 2017, 15:31

http://images.anandtech.com/graphs/graph11170/85887.png

http://images.anandtech.com/graphs/graph11170/85886.png

Not what I expected :-(

The full list of tests on AnandTech (http://www.anandtech.com/show/11170/the-amd-zen-and-ryzen-7-review-a-deep-dive-on-1800x-1700x-and-1700/19)

....
We see a lot of benchmark results where AMD is clearly equal or above Intel's HEDT parts in both ST and MT. However there are a few edge cases where AMD is lacking behind 10-20% still, even to Broadwell. These edge cases are difficult to anticipate, and can stem from unoptimized code.
...
Senior Engineer Mike Clark says he knows where the easy gains are for Zen 2, and they're already working through the list.
...

birdie

2nd March 2017, 15:46

birdie

2nd March 2017, 16:29

A few more benchmarks:

https://3dnews.ru/assets/external/illustrations/2017/03/02/948466/x264.png

https://3dnews.ru/assets/external/illustrations/2017/03/02/948466/x265.png

benwaggoner

2nd March 2017, 17:50

Hardware.fr:

x264 r2744: --preset slower --tune grain --crf 20 --ssim --psnr

x265 2.1: --crf 16 --preset slower --me hex --no-rect --no-amp --rd 4 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 0.1 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --ssim --psnr
Why such a customized command line for x265 for benchmarking? I think it's best to use as generic a command line as possible to hit the most used and optimized code paths.

JohnLai

2nd March 2017, 18:01

Ryzen x265 benchmark :(
Guess the AVX2 2 cycles 128bit pathway is the reason.
Cause Ryzen performs quite well on x264 which make heavy use of AVX.

pingfr

2nd March 2017, 18:07

@benwaggoner: Poked you a few days ago via messages. ;)

NikosD

2nd March 2017, 18:08

x264 doesn't make use of AVX at all.
Also x265 doesn't make use of AVX.

x264 is using around 5% AVX2 only (meaning that Haswell is 5% faster in x264 than Ivy at the same clock speed)

The x265 results of RyZen 7 are very good, since it's more than 15% faster than Kabylake 7700K

Atak_Snajpera

2nd March 2017, 19:16

In my x265 FHD Benchmark (default x265 settings)
Ryzen7 1800x@4.1GHz = 27.5 fps (2500 frames / 91s)
https://youtu.be/P-TBFf3Sk70?t=4m43s

IPC is around SandyBridge/IvyBridge
https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/
http://i.imgur.com/1SM0BwW.png

So it looks like Ryzen 7 1700 will have similar performance like my old SandyBridge Xeon E5-2690

NikosD

2nd March 2017, 19:38

In
IPC is around SandyBridge/IvyBridge
https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/

Take a better look at that link you posted.

There are workloads that relative IPC of RyZen is faster than Haswell and even Kabylake (!)

Examples from your link:
7zip , Blackscholes, Cinebench 10,11.5, 15, Euler3D, C-Ray, GCC, NAMD, Vampire Numbers

Atak_Snajpera

2nd March 2017, 19:42

On average you have worse IPC than Haswell probably due to FMAC 128bit vs FMAC 256bit.

Motenai Yoda

2nd March 2017, 22:22

The x265 results of RyZen 7 are very good, since it's more than 15% faster than Kabylake 7700K
Yep the 500$ RyZen 1800X is 15% faster than the 340$ i7-7700k

also IPC has no value without power consuption @ same frequencies, and the tune with memory controller, cache l3 and other stuff will go bad on extreme up/down oc

NikosD

2nd March 2017, 22:27

The RyZen 7@3.6GHz is 15% faster than Kabylake, which actually means RyZen 1700 which is a little cheaper than 7700K and has free and automatic overclocking like all RyZen.

cojj

2nd March 2017, 23:30

The RyZen 7@4.0GHz is 15% faster than Kabylake, which actually means RyZen 1700 which is a little cheaper than 7700K and has free and automatic overclocking like all RyZen.

If you are talking about extended frequency range (xfr) - it's not in Ryzen 1700. Only Ryzens with suffix 'x' will have them. Correct me if I'm mistaken.

Personally, I would still prefer 1700 over 7700k

Sagittaire

2nd March 2017, 23:45

Why such a customized command line for x265 for benchmarking? I think it's best to use as generic a command line as possible to hit the most used and optimized code paths.

I make this procedure test with x265 for 1.2 version in 2014 ... ;-)

I use 1080p BD sample with optimized ffmpeg decoding for best possible CPU decoding and best possible x265 encoding (you have 99% charge for CPU for x265 enconding at 100% of charge for each thread)

Anyway don't change anything for result with 265 v2.2 here: Rysen is on par with i7 6900K for x264 and x265 encoding.

ffmpeg\ffmpeg.exe -i sample\sample.ts -an -f rawvideo - | x265\x265_64.exe --input-res 1920x1080 --fps 24000/1001 - -o sample\x265_64.265 --crf 16 --preset slower --me hex --no-rect --no-amp --rd 4 --aq-mode 2 --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 0.1 --bframes 3 --min-keyint 1 --ipratio 1.1 --pbratio 1.1 --ssim --psnr

Sagittaire

2nd March 2017, 23:51

I certainly don't believe that.

Well ... you are wrong.

Rysen R7 is on par with i7 6900K for x264 and x265.

CPC Hardware magazine produce complete test since 2 month in preview for show that.

R7 1700 at 350$ will be certainely the best CPU in market for produce 4K x265 stream with good speed with low price, and by far.

Sagittaire

3rd March 2017, 00:00

Yep the 500$ RyZen 1800X is 15% faster than the 340$ i7-7700k

also IPC has no value without power consuption @ same frequencies, and the tune with memory controller, cache l3 and other stuff will go bad on extreme up/down oc

No it's completely false test, certainely because Anand tech don't sature each thread at 100% in their x264 and x265 test.

If you make x264 and x265 encoding, you know that i7 6900K (8C/16T) is by far better than i7 7700K (4C/8T) for speed in all situation even if you make extreme Overclocking for i7 7700K.

NikosD

3rd March 2017, 08:36

Well ... you are wrong.

I told you that RyZen architecture due to the 128bit FMACs vs 256 FMACs of Intel is going to be around half speed regarding AVX/AVX2 speed.

This is the proof (one of many around the web)
Look at the same clock@3.8GHz results.
Intel has exactly double speed on this AVX bench

https://s8.postimg.org/539y12csl/AVX.png

Rysen R7 is on par with i7 6900K for x264 and x265.

x264 is a lot different app with almost no AVX2 optimizations and RyZen 7 is very fast on that.

Do you have any proof that RyZen 7 is on par with 6900K on x265 ?

NikosD

3rd March 2017, 08:46

If you are talking about extended frequency range (xfr) - it's not in Ryzen 1700. Only Ryzens with suffix 'x' will have them. Correct me if I'm mistaken.

Personally, I would still prefer 1700 over 7700k

No, I thought that too, but I read that XFR works for all RyZen and all mobo chipsets as you can see in techreport's review (one of many reviews actually)

We found that even AMD's Wraith cooler is enough of a heatsink to let XFR kick in on the Ryzen 7 1700 and Ryzen 7 1700X, so it seems as though many folks will be able to enjoy some additional out-of-the-box clock speed headroom without overclocking.

But, it seems that RyZen 7 CPUs have already been pushed to some kind of clock limit, because using precision boost (like Intel's Turbo) and XFR, you can go only 100MHz above boost and only if the work load is up to two active cores/ 4 threads.

If the workload is multithreaded, you need good old overclocking to raise the speed of all 8 cores.

Plain 1700 is a good overclocker according to techreport:

On early firmware, we got our $330 Ryzen 7 1700 up to a 3.9 GHz all-core overclock using just the modest AMD Wraith cooler.
With those settings, the mildest Ryzen turns into a rather brisk single-threaded performer and a real fire-breather on the cheap for multithreaded workloads.
We expect buyers willing to tweak a bit will be happy with the performance they can extract from a Ryzen 7 1700 and an affordable tower heatsink like the Cooler Master Hyper 212 Evo.
We didn't enjoy as much overclocking success with the already-speedy 1700X and 1800X parts, though.

Well ... you are wrong.

I told you that RyZen architecture due to the 128bit FMACs vs 256 FMACs of Intel is going to be around half speed regarding AVX/AVX2 speed.

This is the proof (one of many around the web)
Look at the same clock@3.8GHz results.
Intel has exactly double speed on this AVX bench

https://s8.postimg.org/539y12csl/AVX.png

Rysen R7 is on par with i7 6900K for x264 and x265.

x264 is a lot different app with almost no AVX2 optimizations and RyZen 7 is very fast on that.

Do you have any proof that RyZen 7 is on par with 6900K on x265 ?

Disturbance

3rd March 2017, 12:43

Do you have any proof that RyZen 7 is on par with 6900K on x265 ?

Just adding to the conversation but there is this graph on hardware.fr (http://www.hardware.fr/articles/956-13/encodage-video-x264-x265.html) that for x265 its within 6.6% of the 6900k.

mandarinka

3rd March 2017, 21:12

No, I thought that too, but I read that XFR works for all RyZen and all mobo chipsets as you can see in techreport's review (one of many reviews actually)

But, it seems that RyZen 7 CPUs have already been pushed to some kind of clock limit, because using precision boost (like Intel's Turbo) and XFR, you can go only 100MHz above boost and only if the work load is up to two active cores/ 4 threads.

The XFR allows going 100 MHz over max turbo on the X SKUs, but only by 50 MHz (half of the value for X SKUs) on the non-X ones. It doesn't go further, even if you cooled it with ice or something.

So basically the max clock (with good cooler) becomes 3,9 GHz for 1700X and 3,75 GHz for 1700.

NikosD

3rd March 2017, 21:16

And this is only for 2 cores active.

If the workload is properly multithreaded, the speed drops just 100MHz over the base frequency, so the overclocked speed is 3.5GHz for 1700X and 3.1GHz for 1700.

Sagittaire

4th March 2017, 12:24

Do you have any proof that RyZen 7 is on par with 6900K on x265 ?

yes ... of course ... ;-)

http://www.kitguru.net/wp-content/uploads/2017/03/x265.png

Atak_Snajpera

4th March 2017, 13:12

It looks like Ryzen in integer calculations is at the same level with Intel Haswell

4.4GHz/4.1GHz*30.6=32.8 fps (Ryzen 7 1800X@4.4GHz)

LigH

4th March 2017, 13:29

According to a German blog post (http://blog.fefe.de/?ts=a644bec7), it may be important to support the RyZen architecture specifically; but Windows may not yet be prepared for that completely: an 8 core chip has two "CPU Complex" (CCX) areas, which makes task switching among each of their 4 cores faster than between either complex, so an OS may better handle this CPU like "NUMA-on-a-chip" with two pools. If they can. That may depend on CPU specific drivers for specific operating systems and their awareness of NUMA architectures in their kernels.

It may not be marketing alone that AMD will (at first?) probably not offer drivers for Windows 7, only for Windows 10. Sub-optimal NUMA support per kernel may be another argument. Until proven wrong...

Atak_Snajpera

4th March 2017, 13:41

It may not be marketing alone that AMD will (at first?) probably not offer drivers for Windows 7, only for Windows 10. Sub-optimal NUMA support per kernel may be another argument. Until proven wrong...

I wouldn't worry about drivers for windows7.
http://support.amd.com/en-us/kb-articles/Pages/am4-chipset-driver.aspx

mandarinka

4th March 2017, 13:44

SMT only harms in games and not in all reviews. I spoke with guy who said he measured both and SMT was not harming particularly. It might only happen with HPET, balanced power profile in Windows, or other factors. Also apparently there are bugs in BIOSes ATM, that can disable SMT and so on.

As for x265/AVX2 - some tests are also showing x265 on Ryzen to be close to Broadwell-E, like x264: http://www.hardware.fr/articles/956-13/encodage-video-x264-x265.html

But it is possible that some of these tests only run fast settings that don't do as much analysis and don't use big blocks that would benefit from AVX2?

Sagittaire

4th March 2017, 13:48

and certainely that x265dev (and x264dev?) will produce specifical optimisation to have even better speed for Rysen 7:

1) At this time default command line for x265 is sub-optimized for massive multithreading (6C/12T and more).

https://www.kitguru.net/components/cpu/luke-hill/amd-ryzen-7-1800x-cpu-review/5/

The x265 benchmark is slightly different to Cinebench and Handbrake as it does not saturate the full set of threads on eight- or ten-core chips unless an overclock is thrown into the equation. The data has to be sent fast enough for it to be split and divided up to keep all eight or ten cores fully active, and that’s where clock speed has value.

2) x264 thread optimisation seem really better and Rysen produce result on par with i7 6950K:

http://www.hardware.fr/getgraphimg.php?id=446&n=9

Atak_Snajpera

4th March 2017, 13:54

1) At this time default command line for x265 is sub-optimized for massive multithreading (6C/12T and more).
That's why I run 5 instances of x265 in my x265 FHD Benchmark :) One instance can not saturate my Xeon E5-2690 (8C/16T) on default settings. (CPU usage around 65-75%)

Sagittaire

4th March 2017, 14:00

That's why I run 5 instances of x265 in my x265 FHD Benchmark :) One instance can not saturate my Xeon E5-2690 (8C/16T) on default settings. (CPU usage around 65-75%)

Yes it's exactly true ...

But you can have really better CPU charge on x265 simply with good command line:
--pmode --pme
-- slices 4

Or use 4K encoding for x265 ... ;-)

Sagittaire

4th March 2017, 14:03

Anyway it's sure: Rysen 7 1700 at 350$ will be "the CPU to have" for make video encoding ... :D

Atak_Snajpera

4th March 2017, 14:27

Anyway it's sure: Rysen 7 1700 at 350$ will be "the CPU to have" for make video encoding ... :D
keep in mind that OC beyond 3.5 GHz is just a waste of energy
https://hardforum.com/threads/ryzen-7-1700-b350-overclocking-tidbits.1926296/
https://i.imgur.com/FetxQOo.png

Sagittaire

4th March 2017, 14:51

keep in mind that OC beyond 3.5 GHz is just a waste of energy
https://hardforum.com/threads/ryzen-7-1700-b350-overclocking-tidbits.1926296/
https://i.imgur.com/FetxQOo.png

no ... keep in mind that R7 1700 is 3.0/3.4/3.7 ghz at 65 Watt and i7 6900K is 3.2/3.4/3.7 Ghz at 140 Watt ... :eek:

with simple O/C at 3.8 Ghz you have better perf and less power energy than i7 6900K @stock at 140 watt

R7 1700 have better O/C potential (in %) than all the other R7

Atak_Snajpera

4th March 2017, 15:02

no ... keep in mind that R7 1700 is 3.0/3.4/3.7 ghz at 65 Watt and i7 6900K is 3.2/3.4/3.7 Ghz at 140 Watt ... :eek:

with simple O/C at 3.8 Ghz you have better perf and less power energy than i7 6900K @stock at 140 watt

R7 1700 have better O/C potential (in %) than all the other R7

Still anything beyond 3.5GHz draws too much juice from the wall.
Personally I would stick to sweet spot@3.5GHz.

Sagittaire

4th March 2017, 15:10

Still anything beyond 3.5GHz draws too much juice from the wall.
Personally I would stick to sweet spot@3.5GHz.

Well ...

R7 1700X is 3.4/3.6/3.8 Ghz CPU at 95 Watts
R7 1800X is 3.6/3.8/4.0 Ghz CPU at 95 Watts

AMD seem have the same analyse for power limit ... :)

NikosD

4th March 2017, 16:09

CruNcher

4th March 2017, 16:35

Yes its the same with intel it's more SDP then TDP whoever just judges TDP is not understanding modern workloads at all and all the security precautions inside the Design of Hardware today ;)

Sagittaire

4th March 2017, 17:37

Yes its the same with intel it's more SDP then TDP whoever just judges TDP is not understanding modern workloads at all and all the security precautions inside the Design of Hardware today ;)

We have to wait for reviews from big sites in order to evaluate power consumption and temperature of Ryzen 7 according to its clocks.

Well it's here (french hardware communauty on top ... ;-)
http://www.hardware.fr/articles/956-9/consommation-efficacite-energetique.html

command line for x264 v2744
--preset slower --tune grain --crf 20 --ssim --psnr

x264 speed @stock for 1080p encoding
http://www.hardware.fr/getgraphimg.php?id=440&n=1

Power consommation for this x264 encoding
http://www.hardware.fr/getgraphimg.php?id=442&n=1

efficacity for this x264 encoding (higer is better)
http://www.hardware.fr/getgraphimg.php?id=443&n=1

JohnLai

4th March 2017, 17:45

Hmmm...Sagittaire, any graph for x265?

Sagittaire

4th March 2017, 17:54

Hmmm...Sagittaire, any graph for x265?

No interpretation possible with x265 because all the test in the net use default command line with x265 (certainely with gui like handbrake).

And with default command line all the thread for x265 are not satured and by far, particulary for 8C/16T CPU.

Hardware.fr will perhaps change their test protocole to change that ... ;)

I propose these command line with x265 to have better CPU thread saturation:

--preset slower --tune grain --crf 16 --ssim --psnr --pmode --pme
or
--preset slower --tune grain --crf 16 --ssim --psnr --slices 4

CruNcher

4th March 2017, 20:12

What was the input here ?

Sagittaire

4th March 2017, 20:47

What was the input here ?

frame server from ffmpeg with BD source sample:

ffmpeg\ffmpeg.exe -i sample\sample.ts -an -f rawvideo - | x264\x264_64.exe --input-res 1920x1080 --fps 24000/1001 - -o sample\x264_64.264 --preset slower --tune grain --crf 20 --ssim --psnr

mandarinka

4th March 2017, 21:06

These are not real power consumption numbers.

The 1800X stock is about 112W in prime small fft test, but even climbs up to 140W with other workloads.

We have to wait for reviews from big sites in order to evaluate power consumption and temperature of Ryzen 7 according to its clocks.

How was that measured? In my experience, AMD CPUs stick to their TDP limits unless those are disabled in BIOS and/or there is other form of overclocking.

If your numbers are based on wall power consumption, then they are inflated.
TDP (95 W) is only a rating for the CPU itself. When you meassure power draw on the 12V line for the CPU, then the power consumption you see is actually the draw of the CPU itself + losses of the VRM circuits (up to 20 %). If you measure power consumption of the whole PC at the wall, then you have another 15-20 % of power losses added on top, in addition to the inherent lack of precision in such scenario. Also your measured total consumption will include ramped-up CPU cooling fan (2-4 W, some coolers are rated for 0,7A/12V!) or water AIO pump (even more probably).

So when considering high 85% efficiency for both the PSU and VRM, 95W power consumed by CPU becomes 125 W delta measured, for illustration (95*1,15*1,15 = 125,6).

In any case, Ryzen draws considerably less than X99 chips in load, so it can't have 140W TDP.

CruNcher

4th March 2017, 22:16

Most interesting will be now the Hexa Core/Octa Core + VEGA IGPU Platform CPU launch :)

Looks not bad so far though not interesting at all overall Intel could beat it tomorrow if they want to, but the combination of a Hexa Core + VEGA IP value will be harder to chuck for Intel they had some time advantage now shrinking and advancing the GPU Core but 2H 17 and 1st H 18 are still a possibility to hit now hard with that Hexa Core (Zen) + IGPU Value combination for AMD on AM4 :D

Also targeting the whole Mobile space and bringing Nvidia under pressure as well in the same hit in combination with VEGA ;)

I still predict AMDs breakthrough there coming with massive success, that intel won't really be able to compensate so fast when it hits soon as a complete Modular MultiGPU solution Ecosystem based on Console Development :)

Ryzen looks nice so far but it's not the efficiency Killer that Raven Ridge gonna be :)

The Overall Value is not really high of that Flagship except the 8 Cores but overall to weak for the Overall complexity rise we are currently under.

The G/S line is very interesting in overall Value vs Intel before Kaby Lake X and Coffe Lake hits as we know intel is suddenly ready to ship it sooner now then expected (binned enough Kaby Lake failures to market) ;)

So we will finaly see Hexa Cores from Intel entering Mainstream as well vs the 8/6 Cores of AMD soon.

https://pics.computerbase.de/7/6/7/3/7/8-1080.2705907299.png

Boulder

5th March 2017, 10:52

The only proper way to retain detail is to use --tune grain. That's just the way it is :)

NikosD

5th March 2017, 12:03

One more thing regarding x265 performance of Ryzen and the AVX2 optimizations.

All of the above info and architectural theory of Ryzen internals refers to floating point AVX2-FMA3 implementation.

But x265 uses the integer part of AVX2 and I haven't seen that implementation of Ryzen.

How many 128bit integer ADD/MUL execution units does it have and with what latency and throughout?

Maybe the integer part of AVX2 implementation is faster than FP AVX2

Atak_Snajpera

5th March 2017, 13:42

https://www.purepc.pl/image/news/2017/02/10_amd_zen_mnostwo_szczegolow_dotyczacych_nowej_architektury_12.jpg

LigH

5th March 2017, 13:49

Even though a new CPU generation is interesting for the development of x265, I wonder if such a specific talk about hardware dependencies deserves a thread separate from a rather general and previously more software oriented thread?

@ Moderation: Split?

CruNcher

5th March 2017, 14:58

Is it possible to correct the color change between the screen shots below? The first is the source from bluray and the second is using x265 v 2.3+6. I've updated to v2.3+17 with no change...

http://screenshotcomparison.com/comparison/202364

My settings are below which I pulled from MediaInfo.

cpuid=1173503 / frame-threads=6 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=1470 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=8 / b-adapt=2 / b-pyramid / bframe-bias=5 / rc-lookahead=40 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=3 / rdoq-level=2 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 / limit-refs=2 / limit-modes / me=3 / subme=3 / merange=26 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=2.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=21.0 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / no-hdr / no-hdr-opt / Capture-colorprim=3

A side from the coloring I've tried to improve pic quality without just throwing more bits at it. I've tried dozens of tweaks rd, max merge, ref, rect, amp, aq mode, limit-tu, et cetera.

Even when I increase the CRF from 21 -> 20 or even 19, it doesn't improve much...

Thanks in advance!

Such output differences also make me wonder lately see this difference over here between AMD/NVIDIA and Intel outputs ;)

https://forum.doom9.org/showpost.php?p=1796861&postcount=207

though in your case the source is surely bt 709 and it seems you also flag it that way so it looks like a real chroma difference based on the encoder difference, overall pixel lose can be percepted as a color/lighting difference in your case 3rd Generation.

Most interesting is how his beard changes the perception of it becoming more brownish in your output then black

same for the stony background it gets warmer more saturated as well

Though overall the scene most probably should overall be rather dark it might be you getting a overall wrong picture of how it is supposed to look @ all due to being not correctly calibrated to bt 709, thus why you percepting the difference now stronger with a higher luminance level ?.

If you look really close you see how x265 Psy changed overall the whole appearance of the original overall ;)

First you can see it reconstructed something that is sharper then the original input overall ;)

hmm i guess that is more AQ-Motion it looks like a temporal super resolution like reconstruction ?

birdie

5th March 2017, 15:03

Ryzen 1800X does consume significantly more than advertised:

At least 117W:
https://www.pcper.com/files/imagecache/article_max_width/review/2017-02-27/power.png

At least 125W:
http://hothardware.com/ContentImages/Article/2588/content/power-1.png

At least 106W:
https://i2.wp.com/www.eteknix.com/wp-content/uploads/2017/03/Ryzen-1800x-12.png

brumsky

5th March 2017, 15:25

While I must admit I don't have a solution to your color issue... I must say the loss of details specially on his shoulders is astoundingly awfully bad.

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.

The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

I think if the coloring was correct then it wouldn't look as if as much detail was lost...

brumsky

5th March 2017, 15:32

Such output differences also make me wonder lately see this difference over here between AMD/NVIDIA and Intel outputs ;)

https://forum.doom9.org/showpost.php?p=1796861&postcount=207

though in your case the source is surely bt 709 and it seems you also flag it that way so it looks like a real chroma difference based on the encoder difference, overall pixel lose can be percepted as a color/lighting difference in your case 3rd Generation.

Most interesting is how his beard changes the perception of it becoming more brownish in your output then black

I'm running these tests on a Xeon E5-2683 v4, if that helps at all.

Any thoughts\ideas on how I can correct this? Is the encode bitstarved? I don't think so because increasing CRF from 21->20 is virtually imperceptible - which is about 31% more bitrate. Even increasing CRF from 21->19 doesn't make a note worthy difference.

Sagittaire

5th March 2017, 15:33

Ryzen 1800X does consume significantly more than advertised:

yes but efficacity is really good:
https://forum.doom9.org/showthread.php?p=1799462#post1799462

by far better than all 4C/8T intel CPU. In fact only i7-6900K and i7-6950K are better for fps/power efficacity for x264 encoding (CPU at 100%).

mandarinka

5th March 2017, 15:36

Ryzen 1800X does consume significantly more than advertised:

(...)

Completely wrong, as explained here (https://forum.doom9.org/showpost.php?p=1799497&postcount=4926):

If your numbers are based on wall power consumption, then they are inflated.
TDP (95 W) is only a rating for the CPU itself. When you meassure power draw on the 12V line for the CPU, then the power consumption you see is actually the draw of the CPU itself + losses of the VRM circuits (up to 20 %). If you measure power consumption of the whole PC at the wall, then you have another 15-20 % of power losses added on top, in addition to the inherent lack of precision in such scenario. Also your measured total consumption will include ramped-up CPU cooling fan (2-4 W, some coolers are rated for 0,7A/12V!) or water AIO pump (even more probably).

So when considering high 85% efficiency for both the PSU and VRM, 95W power consumed by CPU becomes 125 W delta measured, for illustration (95*1,15*1,15 = 125,6).

You can't just subtract idle power from load power at the wall, how many times do I have to repeat this?

According to your "math", i7-6950X would have "TDP" of 165 W.

CruNcher

5th March 2017, 16:13

Efficiency is ok but no compare to Intel Kaby Lake as a overall platform, they came close to Sandy Bridge but Intel is already 1 step ahead already of that what AMD released now ;)

Hype is never objective ;)

if you want to compare the efficiency you take a mobile platform and compare them and no desktop anyways ;)

In this case Kaby Lake Laptop vs Raven Ridge as a whole System.

The whole release here was targeted for Gamers entirely every Review shows that, there are some reviewers though that go deeper ;)

https://img.purch.com/o/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS9JL0kvNjU2NDQyL29yaWdpbmFsLzAyLVdhdHRhZ2UtQ3VydmVzLnBuZw==

Would have been nice to have the exact for HEVC and AVC Decoding/Encoding.

Though lot of Reviewer missing significant important data About Power Management setup and Timings, also it seems AMD has the Corepark issue that Intel fixed since some time now (Haswell) ;)

Though don't forget idle data is highly dependent on the GPU used in the review as well as the whole Mainboard target (Component Price Efficiency, useless overhead) ;)

LoRd_MuldeR

5th March 2017, 16:39

Bloax

5th March 2017, 16:41

I would just like to say that it's looking very much like the 329 bux RZ 1700 is pretty much equal to the 489 bux Rz 1800x if you manually overclock it (why wouldn't you), so you should be basing your opinions on that rather than doing erroneous i7-7700k vs. RZ 1800x comparisions.

And for being the same price as the i7-7700k, the Rz 1700 sure blows it out the window for x264/5.

NikosD

5th March 2017, 16:56

Ryzen R7 1700 with its price and performance is the best CPU out there for everything but one.

It's best VFM (value for money) and can replace every CPU and platform for any workload but one.

It can be used as an everyday office/Internet desktop PC or a powerful content creation/productivity/rendering/video encoding workstation.

The only thing missing is 1080p gaming.

For anyone with a powerful GPU and a suitable 1440p or 4K monitor, the Ryzen R7 1700 is the best cpu to buy, again.

But not for 1080p, unfortunately.

That is the one and only weakness of the whole AMD platform/ecosystem.

I hope they find a solution soon.

CruNcher

5th March 2017, 16:56

Sadly Tomshardware made no direct Platform compare (you never really visualize that to hurt sales and make your industry sponsors unhappy, and of course we all need that AMD sells something) like that French Reviewer with his limited Data you have to take out older Review data of Intel Systems and compare yourself ;)

Also what we see here is only a Glimpse of the Efficiency with most a Nvidia Card tested which is in itself crazy the power of this Platform is entirely lying in it's very high efficiency Scalable Modularity in combination with AMD Hardware/Software ;)

And Developers now have to even faster progress on their Multithreading Efficiency ;)

We can hope that the Value will catch buyers so Software improvements get fast on they way, which will become the real value for everyone.

Bloax

5th March 2017, 17:16

Yeah, it's not a total beast in games due to having trouble hitting 4 Ghz (alongside the new Not-Hyperthreading causing performance issues seemingly due to mis-assignment of CPU threads), but this is a video encoding forum, and for that it absolutely wrecks. :)

I guess there's a shitstorm about it because someone thinks it's a terrible CPU or something? :D

Personally then I'm tempted to see if I can set up a capture card -> encoding machine -> vapoursynth -> knlmeans -> x264 streaming machine at some point, with the CPU to crunch that final step being a 1700.

CruNcher

5th March 2017, 17:20

iwod

5th March 2017, 17:29

Pretty much All games and programs on the PC platform are optimised for Intel. AMD, lacking the optimisation now and being completely new uArch, shows huge potential in its current form already.

Hopefully we see more software update that brings even more performance improvement.

NikosD

5th March 2017, 17:29

I guess there's a shitstorm about it because someone thinks it's a terrible CPU or something? :D

I think normal people, not Intel fanboys, are commenting its gaming weakness mainly because it's inconsistent with the rest of its performance and even DX12 multithreaded games are slower than DX11 version of that same game.

Those things shouldn't happen on the release date.

AMD should have already solved them with MS (Windows 10 scheduler) and/or the developers, months ago (and certainly before release time)

All the other reasons to complain can and will be solved with new BIOS/microcode and small patches to applications having issues (see winrar for example)

But gaming could be more difficult to resolve.

Let's go back to x265 now ;)

CruNcher

5th March 2017, 17:37

Did anyone test Ryzen even DX12 with a AMD Card ?

Most reviews i saw yet test with Nvidia and Nvidia Drivers on Win 10 :D

Any RX 480 based Vulkan/DX12 Review GCN based ?

or even better complete Platform compares (would most probably take average Reviewers to long on release needing clicks fast)

NikosD

5th March 2017, 17:40

Yes with R9 Nano and using Win 10 when you disable SMT it gets faster.

Using Win 7, RyZen is about 17% faster (!) in games and probably in general.

Win 7 doesn't suffer from SMT wrong scheduling.

Sagittaire

5th March 2017, 17:48

It will even more wreck for Video Encoding if what i said happens it's not only about Game (VR) Engines ;)

Thus why im absolutely not really interested in this Flagship but Raven Ridge at best with 6 Cores though only 4 will be realizable at first ;)

The G/S series is what im waiting for on AM4 with VEGA IP Internally and external :D

well most test use GTX 1080 for GPU at 700$, i7 7700K at 350$, certainely with top motherboard and RAM ... etc etc etc

If you use configuration between 1500 and 2000$, it's not to play at 1080p with screen at 200$ but more probaly with 1440p or 4K screen with Gsync. And in these condition, you are "GPU limited" and not "CPU limited", and all top CPU produce same fps.

If you want play in 1080p, you use GTX 1060 or RX 480, and with these GPU, all top CPU produce the same fps.

here test with RX 480 (~GTX 1060):
https://www.cowcotland.com/articles/2234-12/test-processeur-amd-ryzen-7-1800x.html
https://www.cowcotland.com/articles/2234-11/test-processeur-amd-ryzen-7-1800x.html

CruNcher

5th March 2017, 17:48

I think you will be disappointed in these "8 cores" of Zen given the lack of AVX units. When AMD refers to "FPU", they actually mean the vector unit. Benchmarks (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/) in x265 show same performance at stock as 7700K. It might appear to be on-par with Intel EE SKUs, but the difference is that 1800X comes out of the factory at maximum clock speed, whereas the i7-EE can go to 4.5 GHz (Haswell) or 4.3 GHz (Broadwell), which will yield another 33% over the 3.0 GHz base clock.

BTW: If cost and power efficiency in threaded applications is your goal, E5-2699v4 (22x 2.2 GHz) is selling for $1750 on Amazon (https://www.amazon.com/INTEL-PROCESSOR-E5-2699V4-2-2GHZ-SMART/dp/B01DTYQH4G)and EBay.

Yes i very much expect Intels new Mainstream 6 Core that's coming as reaction faster then expected to destroy it alone at first.

Im pretty sure it will have AVX1/2 by default

Sagittaire

5th March 2017, 17:52

Using Win 7, RyZen is about 17% faster (!) in games and probably in general.

not for x264 or x265.

There are real problem for 7zip or winrar for exemple on Rysen. It's a specific problem on sub-memory system.

NikosD

5th March 2017, 17:54

I think you will be disappointed in these "8 cores" of Zen given the lack of AVX units. When AMD refers to "FPU", they actually mean the vector unit.

Legacy x87 and SSE instructions are very fast on RyZen due to the 128bit quad issue FPU (2 FADD + 2 FMUL units)

The AVX/AVX2 implementation is slower due to 128bit units vs 256 bit, but only for Haswell and onwards

Benchmarks (https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/) in x265 show same performance at stock as 7700K. It might appear to be on-par with Intel EE SKUs, but the difference is that 1800X comes out of the factory at maximum clock speed, whereas the i7-EE can go to 4.5 GHz (Haswell) or 4.3 GHz (Broadwell), which will yield another 33% over the 3.0 GHz base clock.

You compare apples with oranges.

The overclocked HEDT Intel's CPUs have already a higher TDP and real power consumption figures.
By overclocking them, you only make worse the power/perf ratio which is very good at stock clocks for both platforms.

And as we have already said, if you want to overclock a RyZen CPU then you buy 1700 (non X version)

BTW: If cost and power efficiency in threaded applications is your goal, E5-2699v4 (22x 2.2 GHz) is selling for $1750 on Amazon (https://www.amazon.com/INTEL-PROCESSOR-E5-2699V4-2-2GHZ-SMART/dp/B01DTYQH4G)and EBay.

Very expensive platform overall and not a good overall system with such a low clock.

Sagittaire

5th March 2017, 17:56

Using Win 7, RyZen is about 17% faster (!) in games

I wait this test!
where is the source, please?

NikosD

5th March 2017, 18:13

You are missing the point entirely. If you want threaded performance without sacrificing single-threading, the EE will go to 4.5 GHz (compared with 5 GHz on 7700K), whereas the 1800X can't go beyond 4.1 GHz (and neither can the 1700). E5-2699v4 is incredibly energy efficient, and it has a 3.6 GHz turbo frequency for single-threaded applications (3.3 GHz for four threads). Motherboards are available (https://www.newegg.com/Product/Product.aspx?Item=N82E16813182933)for under $400, which is far cheaper than four X370 boards, PSUs, etc. would cost.

What is the power consumption of HEDT@4.5 GHZ ?

Thermal requirements ?

Cost of CPU and platform ?

Are you seriously comparing a 330$ RyZen R7 1700 with anything else ?

You sure are missing the whole point entirely.

CruNcher

5th March 2017, 18:15

Intel is already reacting to this though with their Mainstream 6 Core which wont be limited instruction wise this time and surely competitively priced.

And especially overall more efficient compensating the 2 cores with the instruction efficiency and gaining the same IPC if not even slightly better.

The non IGPU Chip has in reality no chance Intel can always react fast.

Especially in a unoptimzed Software state the Zen 8 core will be crushed with pure benchmark based reviews by Intels 6 Cores this time, the same Game as previously nothing changed.

Only that the overall efficiency is not that huge apart anymore like it was with Sandy Bridge vs Bulldozer ;)

And AMDs CPUs can't be called heatpipes anymore ;)

AMD needs todo what they can best concentrate on the GPU and HSA, Intel could get ground their 2 using it's shrinking advantage and investing every time saved (AMD was running behind) into the GPU Core Developement.

NikosD

5th March 2017, 18:22

In order for i7 7700K to outperform 1800X in x265, you have to use settings like anandtech's review that are not multithreaded friendly and do not saturate the CPUs.

It's like you are doing that on purpose.

And I'm saying to you again, that overall a 1700 system is best buy compared to i7 7700K or any other CPU that Intel can offer.

Only 1080p gaming can justify a i7 7700K purchase.

Atak_Snajpera

5th March 2017, 18:24

i7-7700K costs $300 and outperforms 1800X in x265. It uses less power as well. Consumers that buy EE CPUs are not interested in energy efficiency, but want MT performance with no compromise in ST. For pure MT performance, as I noted before, Intel has many competitive offerings like the E5-2600v4 series (on sale) or the Xeon-D series for workloads not requiring memory bandwidth.

That's a lie.
http://i.imgsafe.org/c49a5accf4.png

Atak_Snajpera

5th March 2017, 18:37

@Stephen R. Savage

If you had 8C/16T you would already know that x265 CAN'T saturate 16T with 1080p source! I have E5-2690 (8C/16T) so I know what i'm saying. Basically you need two instances of x265 running at the same time to reach constant 100% cpu usage.

CruNcher

5th March 2017, 18:45

NikosD

5th March 2017, 18:48

Sorry but only testing with x265 is blatantly dumb

Sorry, but you have to say that to people testing x265 only.

I'm not that guy, that's why I'm talking about overall system performance from the beginning.

Are you here or are you dreaming ?

Do you even read my posts ?

I can justify people judging CPUs based on x265 performance, only because we are writing on this thread about x265 RyZen.

But I wouldn't call them dump people like you.

hajj_3

5th March 2017, 19:11

I wait this test!
where is the source, please?

https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-8#post-38775732

CruNcher

5th March 2017, 20:49

Sorry, but you have to say that to people testing x265 only.

I'm not that guy, that's why I'm talking about overall system performance from the beginning.

Are you here or are you dreaming ?

Do you even read my posts ?

I can justify people judging CPUs based on x265 performance, only because we are writing on this thread about x265 RyZen.

But I wouldn't call them dump people like you.

Here even the AMD Technical Marketing guy Robert Hallock and im pretty sure he speaks the truth he's more tech guy then marketing ;)

so we have a IPC difference of -6.8% to Kaby Lake confirmed by AMD themselves so im pretty sure the Mainstream 6 Core comming will hit that target they testing here 6/12 Threads overall more efficiently then Ryzen alone ;)

https://youtu.be/TBf0lwikXyU?t=496

Robert Hallock

https://www.youtube.com/watch?v=6Fy1_BEr1DE

Though OBS isn't very efficient on the Capture Side so many Cycles wasted their overall allready

Crazy in their Disclaimer they talk about a I7-6900K tested but in the Video they show a I7-7700K as result ?

Then once they say VBR result and then CBR result are they all MAD over @ AMD ;)

Remembers me about that Nvidia Intern that once upon a time forgot to mention the GTX 970 cutoff MC in the process of the cluster cuts ;)

So you overclock a I7-6900K and then call it I7-7700K ?

https://ark.intel.com/products/94196/Intel-Core-i7-6900K-Processor-20M-Cache-up-to-3_70-GHz
https://ark.intel.com//products/97129/Intel-Core-i7-7700K-Processor-8M-Cache-up-to-4_50-GHz

Thats how you create your results apart from the architectural enhancements just do it like Gamers do it bruteforce and expect the efficiency not to fall apart and create thread deadlocks in the process, very nice way testing the competitors frame drop issues indeed ;)

also overal that fast encoding setup is a real joke

When he talks about better quality :D

Its common wisdom in the streaming community that encoding video on the processor is the best way to go

Sorry but with that Setup it's blatantly nonsense vs ASIC and FPGA efficiency nowadays.

I hate Marketing especially when it comes from someone who should know better, lying in the faces of all who see that Video that's crazy.

Sagittaire

5th March 2017, 22:16

That's a lie.
http://i.imgsafe.org/c49a5accf4.png

well this test is strange. I have other that show opposite result:

http://www.kitguru.net/wp-content/uploads/2017/03/x265.png

and in this test i7-7700K 4C/8T is at 100% for CPU, and all other 8C/16T CPU are not at 100% of charge.

How in first test i7-7700K (CPU 100%) can be at 10% to R7 1800X (CPU 100%) ... and in second test i7-7700K (CPU 100%) can be at 34% to R7 1800X (CPU less than 100%)?

Moreover how i7 7700K at 4.2 Ghz (CPU at 100%) can be at only 34% to i7 6900K at 4.3 Ghz (CPU at 100%) with twice core/thread in multi instance encoding for x265?

In all test on the net, i7 7700K is certainely at 100% for CPU charge and you have better result for R7 1800X with less than 100% for CPU charge.

Sagittaire

5th March 2017, 23:16

and computer base produce really good preview too:

https://www.computerbase.de/2017-03/amd-ryzen-1800x-1700x-1700-test/3/#diagramm-handbrake

brumsky

5th March 2017, 23:22

Just found this review which runs hwbot's x265 benchmark tool.
http://www.overclockersclub.com/reviews/amd_ryzen_7_1800x_1700x_1700/8.htm

I downloaded and ran the benchmark on my Xeon E5-2683 v4 @ 2Ghz 16c/32t, I got 37.5fps. 1700x & 1800x at stock clocks beat my CPU... Once OC'd 1700-1800x smoke my score...

Sagittaire

5th March 2017, 23:23

and for game result is really interessing too:
https://www.computerbase.de/2017-03/amd-ryzen-1800x-1700x-1700-test/4/#abschnitt_benchmarks_in_uhd4k_bei_max_details

this test show that Rysen 7 is on par with all intel CPU for UHD even with Titan X. (GPU limited)

this test show that Rysen 7 well be on par with all intel CPU for FHD with GTX 1060 or RX 480. (GPU limited)

nevcairiel

5th March 2017, 23:41

If you end up GPU limited, its really no big surprise. The CPU isn't a crucial factor anymore. It only matters if you are CPU limited at least on one core, preferably more.

Sagittaire

6th March 2017, 00:08

If you end up GPU limited, its really no big surprise. The CPU isn't a crucial factor anymore. It only matters if you are CPU limited at least on one core, preferably more.

yes but if you use RX 480 or GTX 1060 (or less powerfull GPU) and you play on 1080p screen (or more) then i7 4770K, all Rysen R7 or i7 7700K will produce the same fps for game. And 95% gamers, at least, are in this configuration.

burfadel

6th March 2017, 04:16

There are three main things to know about Ryzen:

a bug in the Windows 10 scheduler such that often the SMT threads are used in favour of the Core threads, resulting in slowdown
--> Windows patch expected, or it may just be / already is? inclouded in the Windows Creators Update due next month
a driver for the CPU, allowing frequency and voltage adjustment etc every millisecond instead of 30 milliseconds, without reduction in power efficiency
--> coming soon (supposedly)
bios microcode and bios specific updates for RAM compatibility, allowing for faster RAM speeds
--> next month or so, encoding will benefit from faster RAM.

These three things together could have a signfiicant impact in certain workloads.

Atak_Snajpera

6th March 2017, 10:32

it is funny that older scheduler in win7 works better with newer cpu ;)

Sagittaire

6th March 2017, 11:13

it is funny that older scheduler in win7 works better with newer cpu ;)

It's just little bug in Win10 bor Ryzen.

Complete explication here:
http://www.hardware.fr/articles/956-24/retour-smt-mode-high-performance.html

You can solve SMT problem just with little modification in base register (+7% in game, just like SMTOff).

MS could make patch really quickly for that.

burfadel

6th March 2017, 13:11

That's a different thing, separate from the scheduler issue. The scheduler issue will be fixed in a Windows update, the performance gained through performance mode will be in a CPU driver.

AzraelNewtype

7th March 2017, 09:34

well this test is strange. I have other that show opposite result:

http://www.kitguru.net/wp-content/uploads/2017/03/x265.png

and in this test i7-7700K 4C/8T is at 100% for CPU, and all other 8C/16T CPU are not at 100% of charge.

How in first test i7-7700K (CPU 100%) can be at 10% to R7 1800X (CPU 100%) ... and in second test i7-7700K (CPU 100%) can be at 34% to R7 1800X (CPU less than 100%)?

Moreover how i7 7700K at 4.2 Ghz (CPU at 100%) can be at only 34% to i7 6900K at 4.3 Ghz (CPU at 100%) with twice core/thread in multi instance encoding for x265?

In all test on the net, i7 7700K is certainely at 100% for CPU charge and you have better result for R7 1800X with less than 100% for CPU charge.

Those results aren't opposite though? The youtube screencap was showing encoding time (lower is better), yours is showing fps (higher is better). In both cases, the Ryzen chip is showing up faster than the 7700K, which is what Atak_Snajpera was arguing. The 6800K falls between them in both too, but there's some disparity about the relative difference between them, particularly when it comes to the overclocks, but only because one of them is overclocked to different speeds between the two tests. It's not affecting the overall ranking of the four chips in common.

simonhowson

8th March 2017, 14:34

Motenai Yoda

8th March 2017, 19:11

I'm hoping there will be an analysis of Ryzen and x265 like this classic analysis of how Intel Nehalem offered dramatic speed improvements for x264.

https://web-beta.archive.org/web/20090115091348/http://x264dev.multimedia.cx

But Nehalem has a couple of stuff over penryn
and RyZen actually doesn't have nothing more, but an smt performance drop which nor intel's, nor older amd's cpus show.
First of all, the Nehalem has a much faster SSE unit than the Penryn. A huge number of SSE operations have had their throughput doubled:

All shuffle instructions
All basic math instructions (add, subtract, bitmath)
Many more complex math instructions (sign, absolute value, average, compare)
All unpack/pack instructions

These changes are hard to take advantage of: they naturally sped up a large number of functions, especially the Hadamard transform (which by definition is just a massive series of adds, subtracts, and unpacks). That is, lots of stuff got faster, but theres no obvious way (as far as Ive found so far) to leverage this for even more of an increase.

The cacheline split problem is basically gone: the penalty is now a mere 2 clocks instead of 12 for a cacheline-split load. This, combined with the SSE speed improvements, made it worthwhile to make SSE2 versions of width-8 SAD functions, despite the fact that this requires more instructions than the MMX versions. This also meant that all cacheline functions throughout x264 were no longer useful, and had to be disabled. One of the great benefits of this is not only making SAD faster, but that every function that made heavy use of unaligned loads got faster, even those with cacheline optimizations, but especially those without. The biggest examples, as per the graph earlier, are bipred and pixel_avg (qpel). To give an idea of the magnitude of this improvement, luma motion compensation for a 1616 block took 150 cycles on Penryn without cacheline split optimization, 111 cycles with, and takes 62 cycles on the Nehalem.

Intel has finally come through on their promise to make float-ops-on-SSE-registers-containing-integers have a speed penalty. So, we removed a few %defines throughout the code that converted integer ops into equivalent, but shorter, floating point instructions.

Sagittaire

8th March 2017, 19:39

But Nehalem has a couple of stuff over penryn
and RyZen actually doesn't have nothing more, but an smt performance drop which nor intel's, nor older amd's cpus show.

actually, the problem for x265 and rysen is that x265 is really unable to saturate 8C/16T CPU with default setting and 1080p source for exemple.

If you want saturate 8C/16T, you must make 4K encoding with x265. There are in fact really impressive potential speed improvement with x265. With CPU charge at 100%, x265 benchmark should be exactly like x264 benchmark, with same relative difference between CPU:

http://www.hardware.fr/getgraphimg.php?id=446&n=9

http://www.hardware.fr/getgraphimg.php?id=446&n=10

In this test, at CPU charge at 100%, R7 1800X and i7 6900K should be at ~12 fps and i7 6950K at ~13 fps.

burfadel

9th March 2017, 04:56

actually, the problem for x265 and rysen is that x265 is really unable to saturate 8C/16T CPU with default setting and 1080p source for exemple.

If you want saturate 8C/16T, you must make 4K encoding with x265. There are in fact really impressive potential speed improvement with x265. With CPU charge at 100%, x265 benchmark should be exactly like x264 benchmark, with same relative difference between CPU:

http://www.hardware.fr/getgraphimg.php?id=446&n=9

http://www.hardware.fr/getgraphimg.php?id=446&n=10

In this test, at CPU charge at 100%, R7 1800X and i7 6900K should be at ~12 fps and i7 6950K at ~13 fps.

Has anyone shown the per-core usage on the 8-core, 16-thread processors? I think it comes down to distribution of threads. Also keep in mind x265 is more complex than x264, and even through parallelisation it still has to wait for the data to complete in the relevant threads before the encode can proceed.

I assume by that graph that there are some actions that are delaying the progression of the encode, it would be good to know what they are then focus on improving their speed through parallelisation or code improvement.

There is also a bug in Windows 10 scheduler allegedly, once fixed the performance should improve a bit under Ryzen.

huhn

9th March 2017, 08:27

you should check out OC ram encoding with ryzen. it is possible already with none OC ryzen.

this is a test that shows remarkable gains for OC ram using on old skylake.
http://www.techspot.com/article/1171-ddr4-4000-mhz-performance/page2.html

OC ram is currently hard to use on ryzen and more tests are needed to confirm benchmarks like this.

broadwell E is using quad channel already so there should be a huge diminishing return for OC ram.

NikosD

9th March 2017, 08:30

According to this table, RyZen has obviously slower AVX2 integer calculations than Broadwell and Skylake/Kabylake.
The table has been created using the internal Instruction Latency and Throughput tool of AIDA64.

RyZen has half speed of Skylake/Kabylake's integer AVX2 addition and quarter speed of Skylake/Kabylake's integer AVX2 multiplication

Broadwell's AVX2 integer speed is between RyZen and Skylake/Kabylake

https://s12.postimg.org/789c14ict/CPU_chart_v16.png

The rest of Instruction Latency & Throughput table is here:

RyZen
http://users.atw.hu/instlatx64/AuthenticAMD0800F11_K17_Zen_InstLatX64.txt

Kabylake
http://users.atw.hu/instlatx64/GenuineIntel00906E9_Kabylake_InstLatX64.txt

We need an ASM developer of x265 to give us his feedback regarding most critical groups of Instructions Mix optimized in AVX2 to compare the architectures of RyZen vs Intel.

simonhowson

9th March 2017, 11:39

According to this table, RyZen has obviously slower AVX2 integer calculations than Broadwell and Skylake/Kabylake.
The table has been created using the internal Instruction Latency and Throughput tool of AIDA64.

RyZen has half speed of Skylake/Kabylake's integer AVX2 addition and quarter speed of Skylake/Kabylake's integer AVX2 multiplication
.
Yeah these were always going to be weaknesses, but I wonder if there are some parts of the Zen architecture that that may be better and can enable optimisations that won't work on recent Intel CPUs? I mean beyond the SMT implementation that seems to be very good.

LigH

9th March 2017, 11:49

Many people already complained about RyZen's AVX2 implementation being slower than top intel implementations; but I assume that it will still be a remarkable speed-up in comparison to not using AVX2 routines (in x265, specifically)? I am just reminded of Phenom-II implementing SSE3 so slow that x264/x265 won't consider using it...

ShogoXT

9th March 2017, 13:47

Atak_Snajpera

9th March 2017, 13:56

Keep in mind currently the higher memory multipliers are broken and the only to get stable beyond 2933 is to have a motherboard with a external clock generator. Currently only available on the ASRock taichi , fatality professional, Asus cross hair 6, and gigabyte aorus gaming k7. You also need single rank ram with Samsung b dies.

I bought my parts today, but went cheap. Ryzen 1700, gigabyte ab350 gaming 3, and gskill aegis 16gb kit 2x8gb 3000. I will probably oc to 3.8 GHz and ram to 2933 and leave it.

I'm have it setup by Saturday or Sunday. Let me know if you want me to test something.
Please test in FlopsCPU and x265 FHD Benchmark.
Make sure that TURBO BOOST is disabled!
http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/

http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/

Bloax

9th March 2017, 14:02

Keep in mind currently the higher memory multipliers are broken and the only to get stable beyond 2933 is to have a motherboard with a external clock generator. Currently only available on the ASRock taichi , fatality professional, Asus cross hair 6, and gigabyte aorus gaming k7. You also need single rank ram with Samsung b dies.

I bought my parts today, but went cheap. Ryzen 1700, gigabyte ab350 gaming 3, and gskill aegis 16gb kit 2x8gb 3000. I will probably oc to 3.8 GHz and ram to 2933 and leave it.

I'm have it setup by Saturday or Sunday. Let me know if you want me to test something.

There seems to be no truly discernable difference between the 1700x and the 1700 if you manually overclock it (and why wouldn't you);

https://www.pcper.com/reviews/Processors/Overclocking-AMD-Ryzen-7-1700-Real-Winner
http://www.hardocp.com/article/2017/03/08/amd_ryzen_1700_cpu_vs_1700x_review

Apparently the 1700/1700x/1800x are binned by voltages, so the 1800x might be able to reach the higher clocks with a lower voltage - but they all pretty much cap out around 3.9 GHz before you have to crank the voltages to the stratosphere, so it's usually not a very significant difference.

LigH

9th March 2017, 14:22

I'd be interested in a comparison to disabled AVX2 usage via --asm option in x265.

NikosD

9th March 2017, 16:34

Please test in FlopsCPU and x265 FHD Benchmark.
Make sure that TURBO BOOST is disabled!
http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/

http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/

While waiting for the RyZen, I did some tests with your beautiful benchmark GUI for x265.

I wanted to see the effect of AVX2 optimizations on x265 performance.

Also, as an update I've tested the Floating Point performance using FlopsCPU.

So, my first system is:

Win 10 x64
Sandybirdge Core i5 2400 with 2 disabled cores
No Turbo
Underclocked to 3.0GHz
12GB DDR3-1333MHz (Dual channel)

My second system is:

Win 10 x64
Haswell Core i3 4170 with Hyperthreading disabled
Underclocked to 3.0GHz
8GB DDR3-1600MHz (Dual channel)

Results x265:

Haswell-2C/2T@3.0GHz -> 5.54 fps

Sandy-2C/2T@3.0GHz -> 3.24 fps

Results FlopsCPU:

Haswell (Single core)-1C/1T@3.0GHz

x86 48 MFLOPS

x87 3.18 GFLOPS

SSE2 7.49 GFLOPS

AVX 14.3 GFLOPS

AVX2 24.1 GFLOPS

Sandy (Single core)-1C/1T@3.0GHz

x86 40.7 MFLOPS

x87 3.09 GFLOPS

SSE2 7.03 GFLOPS

AVX 13.7 GFLOPS

AVX2 optimizations gain for x265 on Intel hardware is ~71% using the same clock, which is absolutely amazing (!)

Keep in mind that utilizing AVX2 for 2C/2T is kind of ideal because it is not memory bandwidth limited.
Using dual channel DDR3-1600MHz for only 2C/2T there is no memory bandwidth saturation and dual channel DDR3 can feed the large 256 ALUs without restrictions.

Double precision FLOPS performance as measured by FlopsCPU is almost the same for Sandy and Haswell, up to AVX instruction set.

But Haswell's AVX2-FMA3 unit is ~69% faster than AVX and makes a huge difference, like AVX2 on integers for x265.

sneaker_ger

9th March 2017, 16:45

Why don't you use the --asm parameter like LigH suggested instead of comparing different systems?

http://x265.readthedocs.io/en/default/cli.html#cmdoption--asm

nevcairiel

9th March 2017, 16:47

Many people already complained about RyZen's AVX2 implementation being slower than top intel implementations; but I assume that it will still be a remarkable speed-up in comparison to not using AVX2 routines (in x265, specifically)?

That depends if someone implemented SSE2/3/4 versions of the same code thats naturally 128-bit. It'll definitely still be faster then C code, there is no question about that.
It would be interesting to benchmark the same algorithm properly optimized in 128-bit SSE(2/3/4) or 256-bit AVX2 using Ryzens 128-bit execution ports, and compare those numbers.

NikosD

9th March 2017, 16:51

Why don't you use the --asm parameter like LigH suggested instead of comparing different systems?

http://x265.readthedocs.io/en/default/cli.html#cmdoption--asm
There is no such thing in that specific benchmark GUI of x265

burfadel

9th March 2017, 16:53

While waiting for the RyZen, I did some tests with your beautiful benchmark GUI for x265.

I wanted to see the effect of AVX2 optimizations on x265 performance.

So, my first system is:

Win 10 x64
Sandybirdge Core i5 2400 with 2 disabled cores
No Turbo
Underclocked to 3.0GHz
12GB DDR3-1333MHz (Dual channel)

My second system is:

Win 10 x64
Haswell Core i3 4170 with Hyperthreading disabled
Underclocked to 3.0GHz
8GB DDR3-1600MHz (Dual channel)

Results:

Haswell-2C/2T@3.0GHz -> 5.54 fps

Sandy-2C/2T@3.0GHz -> 3.24 fps

AVX2 optimizations gain for x265 on Intel hardware is ~71% using the same clock, which is absolutely amazing (!)

Keep in mind that utilizing AVX2 for 2C/2T is kind of ideal because it is not memory bandwidth limited.
Using dual channel DDR3-1600MHz for only 2C/2T there is no memory bandwidth saturation and dual channel DDR3 can feed the large 256 ALUs without restrictions.

Those are two different systems though on two different architectures. Haswell also makes use of FMA3 which the Sandy Bridge CPU doesn't so that will throw the results. What will further throw the results is the IPC speed difference at a given frequency between the two architectures.

If you view here:
http://x265.readthedocs.io/en/latest/cli.html#performance-options

You can see that you can disable the use of AVX2 on the Haswell machine. That would give the clearest indication as everything else is exactly the same. To do this see the list of registers your Haswell lists when x265 is running, then specify all of them in the command line under the --asm option apart from AVX2. Since you are comparing with and without AVX2 you can enable FMA3, that's fine :).

NikosD

9th March 2017, 16:57

Haswell also makes use of FMA3 which the Sandy Bridge CPU doesn't so that will throw the results.

I have already said in x265 encoder thread - and the developers of x265 had already confirmed - that x265 encoder doesn't use FMA3 or any other floating point SIMD instruction set.

Also, as I replied to sneaker_ger, the benchmark is not customizable.

ShogoXT

9th March 2017, 19:37

Atak_Snajpera

9th March 2017, 19:41

AVX2 optimizations gain for x265 on Intel hardware is ~71% using the same clock, which is absolutely amazing (!)
Make sense because Intel's pdf shows identical speed up
https://i.imgsafe.org/1a17f0a24c.png

NikosD

9th March 2017, 20:32

Im curious as well if there is a way to add in the --asm command for that program. Otherwise id have to download a different one as id like to not mess with the staxrip config too much atm. I havent updated its x265 in a while...

StaxRip has nothing to do with that GUI.

The GUI uses it's own x265.exe v2.2 and its own video samples, that why it's ~190MB download.

Think of it as a completely separated package and don't be afraid of it ;)

Make sense because Intel's pdf shows identical speed up
https://i.imgsafe.org/1a17f0a24c.png

Yes, but that slide refers to floating point calculations using AVX2-FMA3 and has nothing to do with x265.

I would call it a coincidence of the same level of optimizations of the two workloads (x265 and the slide's workload) using double resources for both compared to Sandy.

ShogoXT

9th March 2017, 20:36

StaxRip has nothing to do with that GUI.

The GUI uses it's own x265.exe v2.2 and its own video samples, that why it's ~190MB download.

Think of it as a completely separated package and don't be afraid of it ;)

Yes, but that slide refers to floating point calculations using AVX2-FMA3 and has nothing to do with x265.

I would call it a coincidence of the same level of optimizations of the two workloads (x265 and the slide's workload) using double resources for both compared to Sandy.

No worries it looks like a great piece of software and I will definitely use it. I was originally curious about AVX2 testing as well though, and in order to test --asm otherwise id have to install ripbot264 and run one of my blu ray movies on it as a decent test. My Staxrip is on another project atm, which is what I been using and just didnt want to change settings.

For this test though im sure I need to use 2.2 x265 because of optimizations and such.

Im still scrub enough that I never tried to go full text based scripting on Avisynth and Vapoursynth. I just edit GUI scripts.

NikosD

9th March 2017, 20:43

For this test though im sure I need to use 2.2 x265 because of optimizations and such.

I think there is a misunderstanding.

You don't have to install, use or script anything.

The GUI is completely automated with its own scripts, x265 executable and video samples.

You only press a button called "Start"

It can't be easier than that!

ShogoXT

9th March 2017, 21:02

I think there is a misunderstanding.

You don't have to install, use or script anything.

The GUI is completely automated with its own scripts, x265 executable and video samples.

You only press a button called "Start"

It can't be easier than that!

Im sorry I must be wording it incorrectly.

I will be using that benchmark for sure . I could tell right away it was a enclosed program which makes it easy. I never thought there would be additional setup.

But if I wanted to test with --asm like what LigH asked, I would have to go about it another way, AFTER I ran the other tests first. Thats what I meant.

NikosD

9th March 2017, 21:04

OK.

Maybe Atak_Snajpera could add those options as checkboxes in the GUI in order to select instructions sets.

It would be useful for testing.

NikosD

11th March 2017, 13:26

Legacy x87 and SSE instructions are very fast on RyZen due to the 128bit quad issue FPU (2 FADD + 2 FMUL units)

The AVX/AVX2 implementation is slower due to 128bit units vs 256 bit, but only for Haswell and onwards

I have to correct myself on that one.

AVX instruction set doesn't see a fused multiply-adder (FMAC) unit as such, but as an FMUL or FADD unit because AVX doesn't have those commands in its instruction set (FMA)

So, Sandy, Ivy, Haswell and onwards should have similar performance on FP AVX commands, as long as they don't change significantly the execution units (lower latency, better throughput with an addition of more FMAC or FADD or FMUL execution units etc)

Likewise RyZen could be equally fast with Intel HW on AVX instruction set using those 2x128bit FADD + 2x128bit FMUL execution units to process 256 bit FADDs and FMULs.

It would be interesting though, to see if AVX execution path is faster or slower than FMA3 on RyZen, as it supports both but without pure 256bit FMACs (it combines 2x128bit FADD+FMUL to run such code)

NikosD

11th March 2017, 13:34

I bought my parts today, but went cheap. Ryzen 1700, gigabyte ab350 gaming 3, and gskill aegis 16gb kit 2x8gb 3000. I will probably oc to 3.8 GHz and ram to 2933 and leave it.

I'm have it setup by Saturday or Sunday. Let me know if you want me to test something.

If you have already setup your RyZen system or you are going to do it this weekend, I want to ask you for a small (I think) favor.

I want you to run both apps and post your results - FlopsCPU (single core) and x265 benchmark (GUI) - but by disabling from your BIOS:

a) Precision Turbo
b) SMT ("hyper-threading")
c) XFR

also disable 6 cores (if possible) in order to have only 2 active and make sure your CPU runs at 3.0GHz and stays there.

So, you will end up to a RyZen 2C/2T@3.0GHz in order to directly compare it with Sandy and Haswell.

Here is my updated post:
https://forum.doom9.org/showthread.php?p=1800292#post1800292

NikosD

11th March 2017, 13:40

Atak_Snajpera

11th March 2017, 17:15

http://i.imgsafe.org/41ba1e2822.png

I think it would be more clear if you rename in your FlopsCPU GUI the AVX2 checkbox to FMA3.

Because it must be clear that we are talking about Floating Point performance only and AVX2 has nothing to do with that actually.

FMA3 is a different instruction set and CPUs without AVX2, like Piledriver, support it.

The major misconception comes from the fact that both AVX2 for integers and FMA3 for Floating Point were presented by Intel in one concept releasing Haswell that supports both.

Intel compiler does not support FMA3 outside AVX2 code so AVX2 label is correct. AVX2 code crashes on AMD FX cpus even if they support FMA3. Tested.

NikosD

11th March 2017, 17:24

Are you sure that those results are correct for Zen ?

They are a little weird, but probably because the executable is Intel optimized by an Intel compiler.

Are you familiar with GCC compiler ?
Because I'm not.

Buy maybe GCC has different results.

Atak_Snajpera

11th March 2017, 17:53

Are you familiar with GCC compiler ?
Because I'm not.

Buy maybe GCC has different results.
GCC sucks! http://stackoverflow.com/questions/41363902/gcc-6-1-0-vs-intel-compiler-15-and-auto-vectorization-performance

Are you sure that those results are correct for Zen ?
https://forum.doom9.org/showthread.php?p=1800506#post1800506

ShogoXT

12th March 2017, 06:35

Did this in a hurry. OCed to 3.6ghz, but didnt reformat yet, so its not optimal. Cant disable cores, made sure power is on high performance mode. Dont have my noctua yet, so will have to OC more later.
http://i.imgur.com/TpqPXcr.jpg
http://i.imgur.com/HNdZO5z.jpg
http://i.imgur.com/EZlIW5K.jpg

mandarinka

15th March 2017, 01:41

Windows 10 core parking (under balanced power plan) might impact encoding performance on Ryzen too, unexpectedly (from a czech forum (http://pctforum.tyden.cz/viewtopic.php?p=9251681#p9251681)).

http://abload.de/img/ryzen_coreparking6lkdn.png

(This should be R7 1800X.)

Romario

15th March 2017, 02:06

How to disable core parking on Windows 10 X64?

Another question for x265_project. Can you, please, tell me when we can expect specifically optimizations for AMD Ryzen.

Gesendet von meinem GT-I9295 mit Tapatalk

LigH

15th March 2017, 08:35

(under balanced power plan)

Sounds like the "Energy" management in the control panel.

mandarinka

15th March 2017, 12:45

How to disable core parking on Windows 10 X64?

For now, set power plan to "High Performance" instead of the default "Balanced". It is in the power settings, acessible when you right click start button for example.

According to this (https://community.amd.com/community/gaming/blog/2017/03/13/amd-ryzen-community-update?sf62107357=1), AMD will supply driver update for Windows 10 that will update the balanced power plan to close the performance gap with HP plan. After that, it probably won't be necessary to do this.

sneaker_ger

15th March 2017, 13:03

Ryzen 8C/16T is basically dual 4C/8T, right? But it only shows as a single NUMA node. I wonder if there's any chance this could be changed (BIOS/Microcode/Windows update?) and would improve x265 performance further. Or if x265 could pin the threads by itself somehow.

LigH

15th March 2017, 13:26

Already mentioned (https://forum.doom9.org/showthread.php?p=1799427&highlight=numa#post1799427); it would indeed be recommendable to separate NUMA nodes between the "CPU Complex" (CCX) units.

Romario

15th March 2017, 17:16

@ x265_Projekt

Can you, please, tell me when we can expect specifically optimizations for AMD Ryzen.

Gesendet von meinem GT-I9295 mit Tapatalk

LigH

15th March 2017, 19:00

Probably not much earlier than AMD delivers solutions for OS based support optimization... and there are new speculations about the reason, and they seem to target the cache efficiency and memory access. This German blog entry (http://blog.fefe.de/?ts=a637b152) quotes two mails with theories; the second is more verbose and explains that the AM4 socket may have too few lanes for unsaturated RAM access, and the communication to the second CCX may have to pass through the first. Too specific for my knowledge ... put savvy people may find these thoughts useful as inspiration.

mandarinka

16th March 2017, 15:28

http://www.anandtech.com/show/11202/amd-announces-ryzen-5-april-11th

Ryzen 5 chips with 4 or 6 cores will be available on april 11th, pricing matches the Core i5 processors (well, the cheapest one is somewhat lower, comaptable to i3-7350K, but I don't think anybody encoding is interested in souped-up dualcores).

VincAlastor

17th March 2017, 11:43

This AVX2 build is the fastest x265 build on my ryzen for the moment

http://msystem.waw.pl/x265/

Are there any faster builds or specific ryzen patches out? :)

LigH

17th March 2017, 11:52

NikosD

17th March 2017, 11:58

This AVX2 build is the fastest x265 build on my ryzen for the moment

http://msystem.waw.pl/x265/

Are there any faster builds or specific ryzen patches out? :)
There are some benchmarks here if you are interested in:

http://forum.doom9.org/showthread.php?t=174408

Which exactly version is the fastest ?

The MS Studio 2017 AVX2 ?

It would be interesting if you could put your ryzen at 3.0GHz and leave active only 2 cores with 2 threads only.

VincAlastor

17th March 2017, 12:18

Check the commit log (https://bitbucket.org/multicoreware/x265/commits/); do you see any Ryzen specific assembler optimizations committed? Me not yet... :rolleyes:

Cool down from the hype, everyone. Someone has to write the code.

Why? I'm soooo damn happy and thankful that AMD released a cpu with funny useful boxed cooler for 359 € pack so i'm not sad to say goodbye to my 2500k with lovely prolimatech genesis 2x vortex edition cooler - i just can hype it! i were waiting 4 years (after 2 years of use it) for intel to replace it's own 2500k... aahhh i can't understand why you and many other x265/x264/av1-prosumer don't wanna hype ryzen. :) There is no reason! And it's not a shame to bought an expensive intel 8 or 10 core cpu! :)

There are some benchmarks here if you are interested in:

http://forum.doom9.org/showthread.php?t=174408

Which exactly version is the fastest ?

The MS Studio 2017 AVX2 ?

It would be interesting if you could put your ryzen at 3.0GHz and leave active only 2 cores with 2 threads only.

yeah exactly the following build:

http://msystem.waw.pl/x265/x265-2.3+22-db5e22b_vs2017-AVX2.7z

tested all actually 10bit_x64 builds from
http://x265.ru/en/builds/
and
https://builds.x265.eu/
besides AVX and AVX2 builds from
http://msystem.waw.pl/x265/

your two core test has to wait until i'm finished my own "boxed cooler (with conductonaut liquid metal)-avx2-x265-overclocking-challenge" ^^

VincAlastor

17th March 2017, 12:33

Yes it's exactly true ...

But you can have really better CPU charge on x265 simply with good command line:
--pmode --pme
-- slices 4

Or use 4K encoding for x265 ... ;-)

thank you very much for the tip! Sadly it's not effective.slower and only upto 5 % more charging with all these configs:
x265 --pmode --pme
x265 --pmode
x265 --pme
x265 --slices 4 <-- rises bitrate upto 3x! Don't use it ^^

NikosD

17th March 2017, 12:56

thank you very much for the tip! Sadly it's not effective.slower and only upto 5 % more charging with all these configs:
x265 --pmode --pme
x265 --pmode
x265 --pme
x265 --slices 4 <-- rises bitrate upto 3x! Don't use it ^^
Take a look on these benchmarks:

http://forum.doom9.org/showthread.php?p=1800781

VincAlastor

17th March 2017, 17:01

Take a look on these benchmarks:

http://forum.doom9.org/showthread.php?p=1800781

very interesting, thank you but i can't find the connection to --pmode --slices or --pme ^^ if "Sagittaire" was using these parameters for your test you should better do it again :)

anyway: a few weeks ago a friend and me benched my old 2500k@4,6GHz and his 4790k@stock/no delid with these x265 avx/avx2 builds and were getting nearly the same results like you :) 3 years ago i holt a haswell cpu in my hand and wanted to buy it but to this time there were no 62% gain to find in video coding :/

what file and exe i should use for your clock-cleaned dual core test?

NikosD

17th March 2017, 17:07

what file and exe i should use for your clock-cleaned dual core test?

You can use exactly these settings and executables from this link
http://jfl1974.free.fr/Benchmark.zip

Just run the benchmark.bat file with High performance power profile (although with just 2C/2T CPU it shouldn't matter)

VincAlastor

17th March 2017, 18:44

You can use exactly these settings and executables from this link
http://jfl1974.free.fr/Benchmark.zip

Just run the benchmark.bat file with High performance power profile (although with just 2C/2T CPU it shouldn't matter)

wanted to run it now, but can't disable SMT on asus x370 prime pro for you at the moment. Have to wait for this function in upcoming bios update. i'm sorry.

NikosD

17th March 2017, 18:47

I think you have to disable everything in order to disable SMT.

For example you have to disable XFR and precision turbo.

Can you give it a try ?

VincAlastor

17th March 2017, 19:00

I think you have to disable everything in order to disable SMT.

For example you have to disable XFR and precision turbo.

Can you give it a try ?

i were giving it 3 tries for you guys ^^ but it's not possible at the moment. Some gamers wrote this too by trying to disabling SMT on prime pro at the moment

here you find the newest manual in case i couldn't see it:

http://dlcdnet.asus.com/pub/ASUS/mb/SocketAM4/PRIME_X370-PRO/E12577_PRIME_X370-PRO_UM_v2_web_only.pdf

NikosD

17th March 2017, 19:19

i were giving it 3 tries for you guys ^^ but it's not possible at the moment. Some gamers wrote this too by trying to disabling SMT on prime pro at the moment

here you find the newest manual in case i couldn't see it:

http://dlcdnet.asus.com/pub/ASUS/mb/SocketAM4/PRIME_X370-PRO/E12577_PRIME_X370-PRO_UM_v2_web_only.pdf
No it doesn't write something specific.

Try to put Ai overclocking/tweaker to manual and see if any options appear like SMT

VincAlastor

17th March 2017, 20:01

No it doesn't write something specific.

Try to put Ai overclocking/tweaker to manual and see if any options appear like SMT

i'm overclocked i use all manual modes and btw that's the only way you can deactivate XFR and precision turbo. the function "SMT on/off" will appear in advanced cpu menu where you can find function "deactivating 2/4/6 cores" later.

if you want i only can say x265 using 2 threads at the moment. If you want to find SMT on/off in my BIOS let's do it with PM please because it's a little bit off topic :)

LoRd_MuldeR

18th March 2017, 15:51

FMA3 bug in Ryzen processor has been confirmed, workaround seems to be on the way:
* https://www.heise.de/newsticker/meldung/AMD-bestaetigt-FMA3-Bug-bei-Ryzen-3658407.html
* https://www.golem.de/news/fma3-instruktion-windows-smt-bug-laesst-ryzen-systeme-abstuerzen-1703-126770.html

We are aware of select instances where FMA code can result in a system hang. We have identified the root cause and will soon release BIOS updates to motherboard vendors that will resolve the issue. Please watch for new BIOS updates from your motherboard vendor to incorporate these changes.

Sounds familiar? Didn't Intel's Skylake have an FMA3-realted bug (https://www.extremetech.com/computing/220953-skylake-bug-causes-intel-chips-to-freeze-in-complex-workloads) as well? ;)

NikosD

18th March 2017, 16:24

FMA3 bug in Ryzen processor has been confirmed, workaround seems to be on the way:
https://www.heise.de/newsticker/meldung/AMD-bestaetigt-FMA3-Bug-bei-Ryzen-3658407.html

There is no such thing as FMA3 bug for RyZen and it's already fixed.

The only issue is for non-overclocked systems with low power at the CPU that hangs under a series of FMA3 instructions.

But that is not a bug like Pentium's FDIV bug or Haswell's TSX.

It's a motherboard's issue already fixed with a microcode in newest BIOS.

All the other headlines you read is for extra clicks and negative buzz around RyZen.

http://forum.hwbot.org/showpost.php?p=480922&postcount=30

LoRd_MuldeR

18th March 2017, 17:05

The only issue is for non-overclocked systems with low power at the CPU that hangs under a series of FMA3 instructions.

So, if the processor runs with stock(!) clock settings and executes a perfectly valid/legitimate series of FMA3 instructions, the whole system reproducibly locks up.

If that isn't a bug, then what is? And, if you see the link I posted above, AMD engineers have confirmed the bug ;)

It's a motherboard's issue already fixed with a microcode in newest BIOS.

Nope. From all the information available so far (and confirmed by AMD) it is a processor bug. They plan to workaround the bug via microcode update, as described in the articles I posted. That's why it will be shipped via "BIOS update".

And, by the way, that's nothing unusual at all. All CPU vendors provide bug-fixes via microcode update regularly. Intel did it with Skylake as well to fix/workaround the FMA3 bug.

it's already fixed

Not really. They say "We have identified the root cause and will soon release BIOS updates to motherboard vendors", which means the fix is currently worked on and will soon™ be available to motherboard vendors.

When exactly a "BIOS update" containing the fix (i.e. updated microcode) will be available to end-users totally depends on how fast the individual motherboard vendor will react...

NikosD

18th March 2017, 17:20

So, if the processor runs with stock(!) clock settings and executes a perfectly valid/legitimate series of FMA3 instructions, the whole system locks up.

If that isn't a bug, then what is? And, if you see the link I posted above, AMD engineers have confirmed the bug ;)

Nope. From all the information available so far (and confirmed by AMD) it is a processor bug. They plan to workaround the bug via microcode update, as described in the article I posed. That's why it will be shipped via "BIOS update".

And, by the way, that's nothing unusual at all. All CPU vendors provide bug-fixes via microcode update regularly. Intel did it with Skylake as well to fix/workaround the FMA3 bug.

Nope, once again. They say "We have identified the root cause and will soon release BIOS updates to motherboard vendors", which means the fix is currently worked on and will soon be available to motherboard vendors.

When exactly a "BIOS update" containing the fix (updated microcode) will be available to end-users totally depends on how fast the individual motherboard vendor will react...

We have probably different definitions of a bug, as I've already told you.

It's not a bug like Pentium's, Haswell's etc.

It's an issue of low power at stock speed and my link tell us that it has already been addressed and fixed by early February.

Since we have already mid March, I think we can call this "bug" fixed ;)

Anyway, I have an announcement to all RyZen owners.

This is the notorious FMA3 RyZen killer:
https://github.com/Mysticial/Flops/blob/master/version2/binaries-windows/x64-13-Haswell.exe

Could you please run it on your systems (stock or overclocked) and tell us the results ?

Does your system hang ?

NikosD

18th March 2017, 17:22

Intel compiler does not support FMA3 outside AVX2 code so AVX2 label is correct. AVX2 code crashes on AMD FX cpus even if they support FMA3. Tested.

I don't own an AMD FMA3 capable CPU like Piledriver, but I tested the opposite and it works like a charm.

The FMA3 flops optimized executable for Piledriver (128bit FMA3) below, has exactly the same speed like 128bit FMA3 for Haswell and of course it doesn't crash.

What does crash though, using that executable, is FMA4 which obviously is not supported by Haswell.

Piledriver FMA3/FMA4 optimized executable:
https://github.com/Mysticial/Flops/blob/master/version2/binaries-windows/x64-12-Piledriver.exe

Haswell FMA3 optimized executable:
https://github.com/Mysticial/Flops/blob/master/version2/binaries-windows/x64-13-Haswell.exe

mandarinka

19th March 2017, 00:28

It really is a CPU bug, but these might not necessarily be a big deal today - all CPUs ship with tens of errata, some of which can cuase hangs or other problems. As long as the microcode update fixes it without much adverse effects, it's business as usual and nothing to freak out about.*

As Lord Mulder points out, this is pretty much the same deal as with the Skylake bug - erratum discovered too late that needs to be patched by microcode update.

http://forum.hwbot.org/showpost.php?p=480922&postcount=30

The issue with Flops was found and fixed in the beginning of february.
The current µcode version dates to 01/27/2017, so the fix is obviously not included yet (due to the time required for validation).
Flops is only affected when the SMT is enabled, so disabling the SMT can be used as a temporary work-around (until the actual fix arrives).

Apparently it has been already discovered before the launch, but the time needed for validation, the testing and release cycle means that the microcode update is still not shipping. Since it is only tripped by that hand-written test software, there is not really a hurry. (Well, we need to see if the fix will affect performance, that is to be seen - at most there should be a hit in FMA instructions using workload so nothing wide-spread).

* Some CPUs don't even post in motherboard if microcode update upload is disabled. The amount of bugs in silicon is really big due to its complexity today. Most today's CPUs probably have numerous stability or hard-freezing bugs that would trip in real usage, all only fixed by microcode update from the BIOS. We just don't know about these because the fixes are committed in the motherboard BIOSes right from the start (but try going Stallman with libreboot which blocks the microcode binary upload and you'll learn how funny can world be if you choose to be silly, heh).

VincAlastor

19th March 2017, 09:37

maybe this could be interesting for some of you:

"Wraith Spire is remarkably good for a stock cooler, able to hold off 120W while remaining reasonably cool. Gone are the days of shitty stock coolers that would run stock-clocked i7's at 90C.

The bad news: 3.8GHz seemed somewhat unattainable on the stock cooler; there was a distinct feeling of thermal runaway (Prime95 would run until temps hit about 76C or so and then crash, but not hard enough to bring down Windows)."*

*
https://hardforum.com/threads/ryzen-7-1700-b350-overclocking-tidbits.1926296/

if you're using thermal grizzly condactonaut liquid metal i can say you'll get 3,85 GHz by max. 78 degrees (in non-AVX CPU stress test)!
By daily use i measured 46C average and 66C max. That means with semi-passive settings in ASUS AI Suite all coolers are off till 60 degrees. Very nice!

AVX/x265 stress test

By running x265 4K (full cpu charging) encode with 3,85 GHz temps will hit about 83C and then ASUS x370 prime pro mainboard will turn off the system with actually BIOS version 0504.
I had to go down to 3,65 GHz and much lower volts to hold 79C over 2 hours.
With these settings you'll get 12 degrees less and 22 watt lower consumption in non-AVX stress tests!
To run 3,85 GHz as system standard and automatically switch to 3,65 GHz when running x265 (or other avx full charging programs) you'll should use ASUS AI Suite again. Set your non-AVX and AVX profiles with their multipliers and volts. Then define all x265.exe from your tools you use as "power app" by setting 3,65 GHz profile.
It's necessary to enable HPET to use ASUS AI Suite. That's not cool but it's only 0,5% less system performance like tests show:
https://www.computerbase.de/2017-03/ryzen-windows-7-benchmark-core-parking/

In future i hope we can set XFR manually or better use it as constant single/dual core turbo officially or with modified BIOS. Then I'm pretty sure you can add further 200 MHz constant for up to 2 cores for same thermal range.

NikosD

19th March 2017, 09:42

AVX/x265 stress test

Can you run this test with stock and overclocked system and tell us the results ?

https://github.com/Mysticial/Flops/blob/master/version2/binaries-windows/x64-13-Haswell.exe

Most interested in stock settings, actually.

VincAlastor

19th March 2017, 10:05

Can you run this test with stock and overclocked system and tell us the results ?

https://github.com/Mysticial/Flops/blob/master/version2/binaries-windows/x64-13-Haswell.exe

Most interested in stock settings, actually.

Really?! I needed 4 days to test overclocking Ryzen R7 1700 with wraith spire stock cooler and now you're interesting in stock frequencies?!?!?! :devil: :D :D :D

just kidding... look at the first link, please. This guy tested from stock to 3,7 GHz (8 cores). I think you can simply add about 20 watts AVX offset.

NikosD

19th March 2017, 10:10

Really?! I need 4 days to test overclocking Ryzen R7 1700 with wraith spire stock cooler and now you're interesting in stock frequencies?!?!?! [emoji317] :D :D :D

just kidding... look at the first link, please. This guy tested from stock to 3,7 GHz (8 cores).
Probably you haven't followed the discussion with Lord_Mulder in previous posts.

That specific executable I told you to test causes a hang or even shutdown of a RyZen system due to a "bug" in a certain mix of FMA3 instructions.

Actually it's just a power virus like Prime95, but on RyZen stock settings system could have more interesting results.

Take a chance !

VincAlastor

19th March 2017, 10:29

Probably you haven't followed the discussion with Lord_Mulder in previous posts.

That specific executable I told you to test causes a hang or even shutdown of a RyZen system due to a "bug" in a certain mix of FMA3 instructions.

Actually it's just a power virus like Prime95, but on RyZen stock settings system could have more interesting results.

Take a chance !

Many online magazines were testing and explained this "bug" and it will be solved/healed in near future. So in real life it's not interesting like a stock R 1700 too. I'm really sorry but i wanted to share realistic results useful in your daily life - for now price-performance-comparison - and i hope other user will sharing other useful tipps like "howto set manually XFR value" or "3,6 GHz CPU with 3600 Mhz DDR4 speed up x265 5%", ...i don't know but i hope you understand what i mean.

NikosD

19th March 2017, 10:38

Yes I see.

From your reply I can understand that it's not resolved yet, at least for your system :D

I agree with all the rest, regarding the big picture.

VincAlastor

19th March 2017, 10:49

Yes I see.

From your reply I can understand that it's not resolved yet, at least for your system :D

I agree with all the rest, regarding the big picture.

I didn't read about a fix for now. And i know it's funny for you and i know why too ;)

But that's the 2nd topic from you which is a little bit offtopic. x265 isn't using this bug code or any FMA3 code, so don't post it in "x265 Ryzen discussion", please.

NikosD

19th March 2017, 10:52

I'm not exactly sure what you think and mean about my posts, I'm under the impression that you have heavily misunderstood me.

Otherwise you would have a more clear mind to see that I wasn't the first to bring that "bug" to the table.

VincAlastor

19th March 2017, 11:48

Already mentioned (https://forum.doom9.org/showthread.php?p=1799427&highlight=numa#post1799427); it would indeed be recommendable to separate NUMA nodes between the "CPU Complex" (CCX) units.

Is this really fixes the CCX windows problem or only the core parking problem?

https://www.reddit.com/r/Amd/comments/601828/how_the_windows_high_performance_mode_is_limiting/

LigH

1st April 2017, 15:00

The current theory is: Non-temporal writes to memory (to avoid delays via the cache that might lead to RAM inconsistency in multi-processor systems, e.g. MOVNTDQ (http://x86.renejeschke.de/html/file_module_x86_id_194.html)) pull the brake. There is a benchmark on Twitter (https://twitter.com/FioraAeterna/status/847472586581712897) by developers of a game "Ashes of the Singularity: Escalation" which reports 31% speedups when avoiding non-temporal writes.

In x265, this seems to happen in plane_copy_core* (mc-a2.asm). Whether it hurts or not, may be subject to future benchmarks.

P.S.:

not some thread scheduling magic, not some special SIMD optimizations. just making it so their MOVNTs didn't cause chip-wide flushes

nevcairiel

1st April 2017, 22:24

If non-temporal writes cause the entire cache to get flushed, thats something AMD should really figure out. They are often used in video decoding when, for example, copying an entire image around, as you may want to avoid polluting the caches when its not going to be further processed right away.

Romario

28th April 2017, 02:25

Ok, is there a plan to optimize audio codecs specifficly for Ryzen ? While, at the moment, situation is very bad, LAME MP3 is totaly unoptimized and also other audio codecs...

LigH

28th April 2017, 07:19

:eek: Will they be able to speed up at all? And if yes, how much? And even more interesting: How much will that decrease the combined conversion time of a whole movie?

I doubt audio conversion is the worst bottleneck in the whole process. And even if the scenario is different... grabbing audio from optical media is probably several times slower than converting it afterwards. Let's do it for the benchmarks; anyone else may hardly notice.

Atak_Snajpera

28th April 2017, 15:18

Ok, is there a plan to optimize audio codecs specifficly for Ryzen ? While, at the moment, situation is very bad, LAME MP3 is totaly unoptimized and also other audio codecs...

Run multiple instances of LAME encoder = problem solved.
LigH is right encoding to mp3 has never been a problem on single core.

LigH

28th April 2017, 16:07

I rather mean: Subjectively, without a proof, I doubt that the MP3 algorithm has an urgent need for SIMD instructions beyond SSE3, in contrast to HEVC taking advantage of AVX2/FMA3. Audio has one dimension less than video, and also probably smaller units of data to process in parallel. But I would still be curious if anyone could point at a specific reason why complex SIMD instructions might speed up specific core routines of audio encoders.

I would not say that LAME is "totally unoptimized". Already a common build like one from RareWares is able to use SSE(2?) and 3Dnow! with assembler routines. Special builds with support for SSE3/4 or AltiVec do exist (http://tmkk.undo.jp/lame/index_e.html). But they are already old (2012). On their own, their speed advantage is noticable; yet, in comparison to a whole movie conversion including video, the advantage of speeding up only the MP3 conversion is marginal.

We are leaving the topic; this thread is about x265.

mariush

28th April 2017, 16:28

Still a bit off topic, it may be worth for some talented people to have a look at optimizing further mp3, considering the patents for it are about the expire completely or have already expired (i think AC3 is close to expiring as well), unlike AAC and newer formats.

So mp3 could be a good alternative (or secondary format) after opus and/or flac in open source applications (with no patents or legal issues to worry about to worry about)

Romario

28th April 2017, 17:10

Ok, but when you direct compare Ryzen performanse on LAME 3.99 and I7 7700k, Intel is way faster. That's big problem, while it's totally unfair to AMD customers.

Can anybody do something to optimize LAME and AAC codes for Ryzen?

Running several instances doesn't

help so much, while Ryzen have
way other architecture as Intel have.

Gesendet von meinem GT-I9295 mit Tapatalk

Atak_Snajpera

28th April 2017, 17:34

Ok, but when you direct compare Ryzen performanse on LAME 3.99 and I7 7700k, Intel is way faster.
7700 can reach 5GHz while Ryzen has serious problems reaching 4GHz. IPC on single core Ryzen is around IvyBridge. The only way to speed up encoding is processing 16 audio files at once. Trust me there is no magic "optimalization trick".

Romario

28th April 2017, 17:44

7700 can reach 5GHz while Ryzen has serious problems reaching 4GHz. IPC on single core Ryzen is around IvyBridge. The only way to speed up encoding is processing 16 audio files at once. Trust me there is no magic "optimalization trick".
Is there any way to do that for only one audio file? Something similar to multithreading?

But still, you can't convince me that one such an old thing, as LAME, haven't space for further optimizations. Am I correct?

Gesendet von meinem GT-I9295 mit Tapatalk

Atak_Snajpera

28th April 2017, 18:52

But still, you can't convince me that one such an old thing, as LAME, haven't space for further optimizations. Am I correct?
Any optimization let's say using AVX2 will make Intel CPU even faster because Ryzen has AVX128+FMA while Intel supports AVX256+FMA.
AMD fights with Intel only with "more cores philosophy".

Btw. You want to encode music collection to mp3 or movie tracks?

LigH

28th April 2017, 21:36

Optimizing MP3 as such (avoiding imminent limits of its specs) has been considered "ages ago" already (see MP+ or MPC). Turned out to be irrelevant.

Implementing algorithms of modern audio codecs with more complex SIMD instructions may be possible. Whether speed-ups will be relevant ot not, has to be tested when it's done. But not every audio codec is OpenSource. One of the quality-wise best AAC codecs is developed by Apple, they will certainly not let us tweak it.

Romario

29th April 2017, 00:36

Any optimization let's say using AVX2 will make Intel CPU even faster because Ryzen has AVX128+FMA while Intel supports AVX256+FMA.
AMD fights with Intel only with "more cores philosophy".

Btw. You want to encode music collection to mp3 or movie tracks?

Music collection and audio CD rips.

LigH

29th April 2017, 08:05

Then you should have opened a new thread in the audio section. Not here in a thread about x265.

I hope our previous posts can be separated now.

Atak_Snajpera

29th April 2017, 12:22

Music collection and audio CD rips.

LameXP can encode multiple files at once. This means that if you have Ryzen 7 you could encode 16 files at the same time.

Nintendo Maniac 64

30th April 2017, 03:09

LameXP can encode multiple files at once.

As can foobar2000, but with any audio format that the player can convert to.

LigH

2nd May 2017, 14:06

Just to have it mentioned ... the German c't computer magazine released benchmark results of RyZen CPU's. Rather artifical and probably CPU instruction focused benchmarks, though (SPECint/SPECfp, different compilers); I guess these results have only marginal impact on the special requirements of x265, especially considering its focus on the memory throughput.

VincAlastor

6th June 2017, 15:53