Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable NVPTX #367

Open
ghost opened this issue Sep 5, 2023 · 5 comments
Open

enable NVPTX #367

ghost opened this issue Sep 5, 2023 · 5 comments

Comments

@ghost
Copy link

ghost commented Sep 5, 2023

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.

@longnguyen2004
Copy link
Contributor

What would be required for that?

@mstorsjo
Copy link
Owner

I merged #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%.

@mstorsjo
Copy link
Owner

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.)

@mstorsjo
Copy link
Owner

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.

@kleisauke
Copy link

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 libvips/build-win64-mxe@ce17ea8.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants