search

BtbN / FFmpeg-Builds

MIT License
7.42k stars 1.02k forks source link

LLVM based toolchain #372

Closed IdrisKalp closed 4 months ago

IdrisKalp commented 4 months ago

Hi

Is it possible to build and use LLVM-based toolchains in these builds?

BtbN commented 4 months ago

The win-on-arm builds use clang, for lack of a a gcc based toolchain. gcc-15 added support for it though, so in the future, that will likely also switch back to ct-ng again. Why?

IdrisKalp commented 4 months ago

I used to do my own builds from scratch with clang. I noticed some performance gain over gcc. Though I'm not sure if all other conditions were same.

Edit: It was mingw-w64 build, also

BtbN commented 4 months ago

It seems unlikely the effort really. clang is not magically faster than gcc. I wouldn't really know how to bootstrap a toolchain for clang either. If you can cook up a working base image, it might work, but would likely need adjustments in all scripts, since a lot of build systems don't expect it.

Andarwinux commented 4 months ago

libc++ is always faster than libstdc++ on win32 because libc++ implemented c++11 thread via win32thread. But gcc14 also implemented c++11 thread based on win32 thread. llvm toolchain for me is mainly better security for proper support of cfguard, cet. if you do need a relatively complete ffmpeg built with clang, you can use mpv-winbuild's ffmpeg. My mpv-winbuild fork also build with PGO (profdata is locally generated) and some audio codecs and prores have 20%-50% performance gain.

BtbN commented 4 months ago

The huge majority of code involved is C, not C++ though. And the most performance critical parts are all written in assembly. There really is no need to pick one toolchain over the other. Getting win-on-arm to build with clang was a huge pain already, which needed a ton of workarounds implemented.

Andarwinux commented 4 months ago

I didn't encounter any serious obstacles when adding aarch64 support to mpv-winbuild-cmake. Most build problems can be solved elegantly by switch build system (autotools->cmake/meson). Only a few software require special adjustments build options to disable things that don't work (tend to be ASM and intrinsics functions), where the SVE issues with aom and libvpx have been fixed upstream, and AVS family of codecs just need disable ASM. rav1e just have to wait rust 1.79. The only ones I've come across that require ugly workarounds are libgme, zimg, libmodplug, etc. which have hardcoded -lstdc++ in their pkgconf, my workaround is to create a symlink from libstdc++ to libc++.

BtbN commented 4 months ago

That seems like quite some obstacles to me. Sorry, but I see zero reason to put in the extra work just to not just keep using gcc.