View Full Version : x265 Ryzen discussion
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
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/
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...
If I do use the --asm command, do I just add in all of them except AVX2? Or Should I specifically target using --asm sse4.2 vs --asm avx2 ?
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
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/
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.
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
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.
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).
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.