x265 Ryzen discussion

[VincAlastor]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

: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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

LameXP can encode multiple files at once.

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

[LigH]

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]

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.

wraith spire boxed cooler test:
3,9 GHz non-AVX2 Stresstest: 89 degrees
3,8 GHz x265 2 parallel encodes for full charging: 92 degrees - without throtting

max Temp about 100 degrees
https://www.computerbase.de/2017-05/cpu-temperatur/