llvm-mingw
llvm-mingw copied to clipboard
mstorsjo
enable NVPTX
Otherwise it's not possible to compile ffmpeg with --enable-cuda-llvm, I don't like to compile this with the distro clang, they're too old.
It seems that simply adding NVPTX to https://github.com/mstorsjo/llvm-mingw/blob/3becea478fab0145f5b6dc9c84736f4a3d3bb65f/build-llvm.sh#L311 This is indeed a problem, if NVPTX support is not enabled, it is not possible to compile FFmpeg with CUDA filter support using llvm-mingw, unless nvcc is explicitly specified as another clang.
I merged https://github.com/mstorsjo/llvm-mingw/pull/385 now, so this should be fixed in future builds (including nightly builds).
FWIW, earlier, one of my main concerns was that the GitHub Actions based builds were getting painfully close to the timeout of 6 hour per build step (it would mostly still run in less time than that, but more often than I would have wanted, builds would time out and would have to be restarted), and any case of enabling more things would make builds time out even more often. But since a few weeks, GitHub Actions have upgraded the runners to much more beefy ones (4 cores instead of 2, and 16 GB of RAM instead of 8), so the builds run much more smoothly now.
I also checked how much longer the build takes overall; a build with all of clang-tools-extra and lldb enabled now, with NVPTX enabled, takes around 5% more CPU time to build. The number of files to build increases from 5763 to 5804, which sounds like little, but apparently those files still take a fair amount of CPU to build if the total amount of work needed to build increases by 5%.
Personally, I'd consider dropping ARM support to offset the build time bloat caused by NVPTX. Microsoft has already dropped arm32.
Personally, I'd consider dropping ARM support to offset the build time bloat caused by NVPTX. Microsoft has already dropped arm32.
I wouldn't quite go so far to drop support for it here, we do have users of llvm-mingw who actively use it in arm32 environments AFAIK - Windows 10 IoT is ARM32, not ARM64 - CC @kleisauke (if I remember correctly).
But anyway, the point is moot, the build time increase is quite tolerable, and supporting ARM32 is something I quite intentionally spend extra effort on even if is being phased out from upcoming OSes - it did exist quite visibly for a number of OS releases. (It's also quite relevant for being able to build e.g. Wine for ARM32.)
A prerelease with LLVM 18.1.0 RC 1 is out now, at https://github.com/mstorsjo/llvm-mingw/releases/tag/20240130, where this issue should be fixed.
I wouldn't quite go so far to drop support for it here, we do have users of llvm-mingw who actively use it in arm32 environments AFAIK - Windows 10 IoT is ARM32, not ARM64 - CC @kleisauke (if I remember correctly).
The libvips Windows binaries, as available in the https://github.com/libvips/build-win64-mxe repo, still continues to build ARM32 binaries on a best-effort basis. Testing these binaries is done manually on a Raspberry Pi 3B running Windows 10 IoT Core.
The maintenance burden is doable; however, I'm considering discontinuing support for ARM32 in the near future, see e.g. work-in-progress commit https://github.com/libvips/build-win64-mxe/commit/ce17ea891ab167ad0ed680cbf6f8bfcb59041020.
