v2.2.1-A - Community Bulids Thread

[gianni-rosato]

Community Builds Thread

This is a place for the community to share unofficial tools not affiliated with the project -- mainly consisting of binaries compiled by community members.

Trust

⚠️ Community-built binaries are not affiliated with the SVT-AV1-PSY project & are to be used at your own risk. If you encounter bugs while using a community-built binary, ensure that you double-check with the person responsible for providing you with the binary before submitting an issue report.

Architecture

When downloading pre-compiled binaries, you might see AVX, AVX2, AVX-512, x86-64-v3, etc. If you don't know exactly what ISA extensions your CPU supports, here is a chart to help you quickly understand your hardware's support:

AMD (Desktop)

Desktop Gen       Architecture       Build
Ryzen 1000        AVX2               x86-64-v3
Ryzen 2000        AVX2               x86-64-v3
Ryzen 3000        AVX2               x86-64-v3
Ryzen 5000        AVX2               x86-64-v3
Ryzen 7000        AVX-512            x86-64-v4

Intel (Desktop)

Desktop Gen                 Archit.  Build
Haswell (4000-series)       AVX2     x86-64-v3
Broadwell (5000-series)     AVX2     x86-64-v3
Skylake (6000-series)       AVX2     x86-64-v3
Kaby Lake (7000-series)     AVX2     x86-64-v3
Coffee Lake (8/9000-series) AVX2     x86-64-v3
Comet Lake (10000-series)   AVX2     x86-64-v3
Rocket Lake (11000-series)  AVX-512  x86-64-v4
Alder Lake (12000-series)   AVX2     x86-64-v3
Raptor Lake (13/14000-ser.) AVX2     x86-64-v3

It is also helpful to know the various options available with C compilers, like what is available when specifying -march & -mtune on x64 CPUs:

Known valid x64 arguments for -march=:

i386 i486 i586 pentium lakemont pentium-mmx winchip-c6 winchip2 c3 samuel-2 c3-2 nehemiah c7 esther i686 pentiumpro pentium2 pentium3 pentium3m pentium-m pentium4 pentium4m prescott nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client rocketlake icelake-server cascadelake tigerlake cooperlake sapphirerapids emeraldrapids alderlake raptorlake meteorlake graniterapids graniterapids-d arrowlake arrowlake-s lunarlake pantherlake bonnell atom silvermont slm goldmont goldmont-plus tremont gracemont sierraforest grandridge clearwaterforest knl knm intel geode k6 k6-2 k6-3 athlon athlon-tbird athlon-4 athlon-xp athlon-mp x86-64 x86-64-v2 x86-64-v3 x86-64-v4 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 lujiazui yongfeng k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 znver3 znver4 znver5 btver1 btver2 generic native

Known valid x64 arguments for -mtune=:

generic i386 i486 pentium lakemont pentiumpro pentium4 nocona core2 nehalem sandybridge haswell bonnell silvermont goldmont goldmont-plus tremont sierraforest grandridge clearwaterforest knl knm skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake sapphirerapids alderlake rocketlake graniterapids graniterapids-d arrowlake arrowlake-s pantherlake intel lujiazui yongfeng geode k6 athlon k8 amdfam10 bdver1 bdver2 bdver3 bdver4 btver1 btver2 znver1 znver2 znver3 znver4 znver5

I'll leave it to you all to look up which options work for your hardware.

• Note: -march=foo implies -mtune=foo unless you also specify a different -mtune. This is one reason why using -march is better than just enabling options like -mavx without doing anything about tuning.

Antivirus

Be wary of antivirus software on Windows detecting EXEs distributed here as malicious software. While they may not always legitimately be malicious, it is important to maintain a healthy level of skepticism when running code that someone else has compiled.

[ItachiUchiha-IU]

If anyone has any idea on how to build with PGO and BOLT on windows (preferably ClangCL as it was always faster in all our tests), pls comment and teach us! (or open something down below or somewhere on github idk)

svt-av1-psy v2.2.1-A

cmake --fresh -B svt_build -T ClangCL -DBUILD_SHARED_LIBS=OFF -DENABLE_AVX512=$ONOFF -DCMAKE_CXX_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=$allmarch" -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=$allmarch"

The zip is a matrioska cause github doesnt support 7z
The zip includes the generic builds: x86-64, x86-64-v2, x86-64-v3, x86-64-v4
and the march specific builds: znver1, znver2, znver4, haswell, broadwell, skylake, rocketlake, alderlake, raptorlake
SvtAv1EncApp-windows-all-march-but-znver3.zip

Always prefer the build optimized for your march to the generic build (or do some testing yourself to see which one is the best for your hardware; in my case, on a ryzen 7900, znver4 is a lot faster than the generic x86-64-v4)
znver3 is missing cause it's bugged on all clang versions we tried (we tried some manual patches but znver2 still seems to be faster iirc, if someone knows how to fix it, teach us!), try znver2 or znver1 and as last resort x86-64-v3

Brief test made on R9 7900 :
  march        encoding time       speed
---------     --------------     ---------
x86-64-v2        00:12:02        11.76 fps
x86-64-v3        00:11:01        12.86 fps
x86-64-v4        00:10:55        12.97 fps
znver1           00:10:50        13.07 fps
znver2           00:10:52        13.03 fps
znver4           00:10:43        13.22 fps

Infos + my findings:

• ClangCL 17.0.3 was used for these builds (the last up-to-date for MSVC as 17.0.6 didnt give any improvement);
  ClangCL 18.1.8 and 19.1.0 were tested too (both through MSVC+ClangCL and Ninja) but they dont work correctly (18 gives a fat binary for znver4 like 17 does for znver3) and both make slower binaries than v17 (this was tested on znver4 and 3); znver3 with v18 and 19 still gets a non-optimal binary
• /O3 (/clang:-O3 as well) always seem to make slower binaries
• On my tests with znver4 Windows11 is faster than W10 by a ~3% (personally Ill keep using W10)
• Ofast must not be used as it changes the final encode (a few scenes) and it's not always faster, sometimes it's even slower
• I recently tested O2 + -ffast-math which gave me faster encoding (by ~2.5%) and didnt change the single 24min file I tested, but I havent tested more than that (so idk if it does actually never affect the final encode and if it is actually faster on other marchs, for now I am using the znver4 binary with the same settings used for the builds posted here)
• on a 7900, with an optimized binary I got 60% speed up compared to a non-optimized build (yes, it seems absurd but it's real); obviously different march will have different gains, but this is just an example of how important optimization is in encoding

Special thx to myself as Im the reason we finally have optimized builds on windows too (let's go!!, and this matter reached even the mainline) and to @Uranite because he's the one who made all this become real, initially coming to verify my doubts about the encoding speeds of the builds available at the time (several months ago), and finding out every possible way to build our binaries in the most optimized ways possibile.
Ulterior thx go to all the other guys in our discord that partecipated in this by helping, testing etc (and that are still partecipating)

Sorry for the long post, this first time I just wanted to give some infos on the work we made to reach this point and thank everyone who helped. If anyone finds anything new we are happy to learn more!
I think I will post my builds every time a new release comes as it doesnt cost me anything and as a thanks to whoever reaches this page, hoping they will be useful to you; moreover, other guys from our discord will also probably post their own builds as it has already happened on the page made for v2.2.1.
Again, all my love goes to all the ppl that helped in reaching this point in the optimization of the binary for windows, and my final thanks go oviously to the psy guys who always do an amazing job.

Finally, if anything doesnt work as it should, feel free to comment so we can find out what I did wrong lmao (I normally just build and post the znver4 and x86-64-v4 binaries on discord so idk if the others will not work properly)

for whoever doesnt know what march they have:

[gitoss]

If anyone has any idea on how to build with PGO and BOLT on windows (preferably ClangCL as it was always faster in all our tests), pls comment and teach us! (or open something down below or somewhere on github idk)

I dunno about BOLT, but for simple PGO I've got some questions / observations :-) ... I'm putting these in the reply to my own thread #69 (reply in thread)

[ItachiUchiha-IU]

Splendid!
Replying there 👍

[Uranite]

arm and arm64 build for Termux
install via dpkg -i
svt-av1.zip

[gitoss]

PGO Guide for LLVM and Visual Studio...

Fo me, enabling PGO results in a single-digit percent speedup - I didn't do a lot of benchmarking, but it's significant, because it's free and I didn't observe speed regressions yet.

Intel users might want to give the free ICC 2024.2 a try that has settings for the various precise Intel platforms and adds "hardware PGO". The new ICX is LLVM-based and even works with -march=znver4 (overriding the front-end), but for my Zen4 it's slower then LLVM 17 or 19.
https://www.intel.com/content/www/us/en/developer/tools/oneapi/base-toolkit-download.html

1. cmake (or use svt's build.bat) and compile - don't forget to switch to Release in the GUI, a :-p

cmake --fresh -B svt_build_llvm -T ClangCL -DBUILD_SHARED_LIBS=OFF -DENABLE_AVX512=ON -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /W0 /clang:-O2 -march=znver4 -mtune=znver4 -flto -fprofile-generate=c:\pgo\llvm.profraw -Xclang -ffast-math"

You can leave out and/or override the .profraw location by settings the LLVM_PROFILE_FILE env var.

2. Encode a short clip (using --frames or prepare a .y4m file), generating the .profraw.

3. llvm-profdata.exe merge -output=C:\pgo\llvm.profdata c:\pgo\llvm.profraw

For LLVM 17 use "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\Llvm\x64\bin\llvm-profdata.exe" or for LLVM 19 installer
"C:\Program Files\llvm\bin\llvm-profdata.exe"

You can automate 1-4 with Intel's one-click PGO (only works with the ICX compiler), or add 2-3 to the VS GUI Build Events=>Post-Build Event.

4. Compile again, but this time with -fprofile-use=C:\pgo\llvm.profdata

You can either re-cmake or edit C/C++=>Command Line in the VS GUI. For LLVM 19 (using https://github.com/zufuliu/llvm-utils) you can set the respective clang options in the LLVM settings in the VS GUI that appear after switching C/C++=>Platform Toolset to LLVM_143.

[gitoss]

I retested with one of the encoding tests I used for profiling. Significant performance gains with both PGO but IR & IR+CSIR were within margin of error I think.

One of my binaries crashed right away, too, but I didn't track what (other) settings I used at this time.

Concerning performance, this is extremly dependent on the profliling step (and the video clip). I tried IR, IR+CSIR with merging profiles from presets 12-2 (took a while), and the result was slower than just profiling the single 3 preset or presets 3-5. Profiling a longer clip is worse than a short clip and so on.

We know IR PGO can have a benefit, otherwise it wouldn't have been merged to mainline. https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2254

As for IR + IR-CS PGO, I dunno yet... not being able to use LTO might be a problem at the moment. My 'lucky PGO' binary is 5%-ish faster than the one provided by the default community build.

What I'm watching for are actual regressions, i.e. a PGO build is slower than without - one case reported in the thread over on mainline for profile 10.

[Ironclad17]

I got IR and IR+CSIR working! The issue was not zone_overrides. Previously, to save time the first 4 encodes of each test clip were done at 1/10th the normal framerate which was the majority of the profiling. This caused crashes on full framerate encodes. Only training with the full framerate resolved the issue. Also my testing shows compelling results. I tested 5 short video clips this time. Test 2 was probably the most complex to encode.

No PGO 29.31, 17.87, 22.27, 20.60, 22.31 fps
-fprofile-use IR 31.12, 15.48, 23.79, 21.80, 23.84 fps, fully working!
-fprofile-use IR+CSIR 31.08, 19.71, 23.56, 21.90, 24.06 fps, fully working!

[gitoss]

I got IR and IR+CSIR working!

Good to know that some specific profiles cause the crashes - that's would by I couldn't track it down. To understand how you got this fps boost, could you please post exactly what you've done?

What I'm currently doing is with general Visual Studio llvm settings "-O2 -march=znver4 -mtune=znver4 -Xclang -ffast-math"

a) compile 1 with -fprofile-generate => did you use -flto=full or -flto=thin in this step?
b) profile 1, convert/merge 1
c) compile 2 with -fcs-profile-generate -fprofile-use=(.profdata from b)
d) profile 2, convert/merge 1+2
e) compile 3 with -flto=full -fprofile-use=(.profdata from d)

By the way, llvm-profdata from llvm 19 has some interesing settings (--enable-vtable-profile-use --enable-vtable-value-profiling --enable-fs-discriminator), however they seem to require lto which doesn't work with the -fcs-profile-generate step. There are clang settings (-fwhole-program-vtables -fforce-emit-vtables) that seem to help this extended profiling for lto=thin

[Ironclad17]

1. Build for generating profiling data. I recommend only setting a directory for profiling data and leaving the naming to defaults.
   cmake --fresh -B svt_build -T ClangCL -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_APPS=ON -DCMAKE_CXX_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-generate="path\to\PGO"" -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-generate="path\to\PGO"" && cmake --build svt_build --config Release
2. IR profiling. Just run the new build on a few test clips. I made a few from seasonal anime I work on with the settings I prefer, but another option for general use is Xiph's test video archive, objective-1-fast. It's also been recommended that a single clip, stefan_sif.y4m is enough.
3. Merge profiling. By default all profiling data for a specific executable will be saved to a single .profraw file, but you still need to convert it to a .profdata file using llvm-profdata. I made a simple python script to assist with this. prof_merge.txt
4. You can stop here for a IR PGO build.
   a.cmake --fresh -B svt_build -T ClangCL -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_APPS=ON -DCMAKE_CXX_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-use="path\to\PGO\IR.profdata"" -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-use="path\to\PGO\IR.profdata"" && cmake --build svt_build --config Release
   b. Or if you also want to use CSIR PGO, build a new generator using the IR.profdata. Note that currently LTO needs to be disabled in this step.
   cmake --fresh -B svt_build -T ClangCL -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_APPS=ON -DCMAKE_CXX_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -march=native -fprofile-use="path\to\PGO\IR.profdata" -fcs-profile-generate="path\to\PGO"" -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -march=native -fprofile-use="path\to\PGO\IR.profdata" -fcs-profile-generate="path\to\PGO"" && cmake --build svt_build --config Release
5. CSIR profiling. Same as before. Notably slower.
6. Merge profiling. This time you're merging the profraw from this profiling with the profdata from the previous profiling. The script handles it.
7. Finally build the IR+CSIR PGO build.
   cmake --fresh -B svt_build -T ClangCL -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=OFF -DBUILD_APPS=ON -DCMAKE_CXX_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-use="path\to\PGO\IR+CSIR.profdata"" -DCMAKE_C_FLAGS_RELEASE="/DNDEBUG /clang:-O2 -flto -march=native -fprofile-use="path\to\PGO\IR+CSIR.profdata"" && cmake --build svt_build --config Release

[gitoss]

2. IR profiling. Just run the new build on a few test clips. I made a few from seasonal anime I work on with the settings I prefer, but another option for general use is Xiph's test video archive, objective-1-fast. It's also been recommended that a single clip, stefan_sif.y4m is enough.

I've tested profiling with the single clip that's used in the mainline pgo script, and all clips from the xiph archive (all 8-bit, often low-res). The result was a lower ir-csir pro binary than using my own high(er) quality fhd clip.

I've tested merging multiple -preset profiles from the same clip - the result is slower or the same as using a single preset.

Of course ymmv, but to me it seems chosing the proper video(s) and then using a single preset profile is the way to go.

I have yet to test if a mix of live and anime content produces a better combined binary, or if even separate binaies (for live/anime, or --scm 0 and --scm 1) is useful.

[gitoss]

I'm attaching sample -march=znver4 PGO binares with LLVM 17 and 19 from the current testing branch. With my Zen4, unlike vanilla builds LLVM 19 with PGO is about the same as (or even a little faster than) Visual Studio's built-in LLVM 17. However, using a laptop with thermal mangement for benchmarking is horrible.

SvtAv1EncApp-llvmpgo_v2.2.1-A-4.zip

[ItachiUchiha-IU]

Thank u for the sample! It allowed me to do a fast comparison, as I will try building with your guide whenever I have the time to do it!!

Here my results of a fast comparision between the builds (no-pgo no-ffastmath is the one in the zip I posted above, no-pgo is my build with -ffast-math which I havent posted for the reasons mentioned in the info/findings section) :

v2.2.1-A -ffastmath      encoding time     speed
pgo-llvm17                 00:10:12      13.87 fps
pgo-llvm19                 00:10:15      13.81 fps
no-pgo                     00:10:18      13.75 fps
no-pgo no-ffastmath        00:10:31      13.47 fps

I think the noticeable speed boost u encountered was cause of the usage of -ffast-math (or did u actually compare with and without -ffast-math yourself? in that case it may be more related to source/settings), but the type of content has surely an impact on the speeds, as I dont know what clip/s u used for the optimization, as well as the settings; so yeah, to see the real differences I think we need to play more with the clips for optimization; for the records, as of now I just made a fast comparison and tested on an anime source that is mostly drawn but with some 3D elements and effects; a "fast comparison" is when I test multiple times a single source or just a few, getting the avg of the multiple tests; a real test would require something quite different that I only do sometimes as it requires more time (maany multiple short clips from different sources tested multiple times).

[gitoss]

I think the noticeable speed boost u encountered was cause of the usage of -ffast-math (or did u actually compare with and without -ffast-math yourself?

I know -ffast-math speeds up encoding by using lossy calculatons - which is fine by me for lossy video encoding, but I understand people might want to have exact reproducibility or maybe care about exact quarter pixel motion estimantion :->

So of course I benchmarked binaries with the same settings, i.e. all -fast-math basic non-pgo llvm 17 vs. pgo llvm 17/19. I'm observing pgo is very dependend on the encoding step, and even encoding different lengths / parts of the same clip results in sigificantly different pgo binaries and performances.

And I guess pgo improvement might depend on the exact cpu, too. My "Zen4" is a single-die AMD Ryzen 7540U - maybe even using a desktop cpu of the same generation with multiple dies or core configuration could have different results.

For me, it seems to be worth it - I have benchmarked enough to tell the speedup on my system is real even considering the unreliable benchmarking on a laptop system with heavy thermal maangement.

Last not least, even your result shows that pgo doesn't hurt - which seems to be different with other / complex apps if the profiling usage is (more) different than the actual usage.

[gitoss]

By the way, official svt chose to merge a commit with this clip for auto-pgo profiling: https://media.xiph.org/video/derf/y4m/stefan_sif.y4m

I have no idea if chosing this specific clip was an educated guess that it might be useful for profiling, or simply was a license-free y4m clip available on the net.

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Build/obj1fastdownloader.cmake?ref_type=heads

The discussion concerning the commit mentions how vastly different pgo restults are for different systems (the commit author claims for his/her system, gcc is faster than llvm). There is a discussion on which presets to use (read it for yourself), too: https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2254