Building Meshroom to test PR #2077 (porting CUDA to SYCL)

[unfa]

As suggested in #439 (comment) I want to move discussion related to building AliceVision/Meshroom out of the PR thread to keep things clean.

I am attempting to build this PR under Arch Linux and/or MX Linux - whichever works better.
All I want is the ability to run this PR and test it on my AMD hardware, namely Radeon RX 6800 XT and Ryzen 9 3900X.

[philippremy]

From what I can tell, your CMake logs indicate that the system has two different versions of Eigen installed. Ceres was built with Eigen5 and now CMake is finding Eigen3.

-- Failed to find Ceres - Found Eigen dependency, but the version of Eigen found (3.4.0) does not exactly match the version of Eigen Ceres was compiled with (5.0.1). This can cause subtle bugs by triggering violations of the One Definition Rule. See the Wikipedia article http://en.wikipedia.org/wiki/One_Definition_Rule for more details

Because Eigen is a header-only library, pulling in different versions could accidentially cause functions to be defined multiple times and from different versions (see the Wikipedia article). If Ceres wouldn't check that, you'd likely get a linker error at some point (which makes debugging much more difficult). I am not a Linux user, but it may be worth uninstalling Ceres and Eigen3 + Eigen5 from your system/package manager and trying again (with ALICEVISION_BUILD_DEPENDENCIES=ON). This should ensure that Ceres and AliceVision eventually find and use the same Eigen version.

[unfa]

Ok, this seems to have worked. I am building now and just got past building eigen:

[ 26%] Completed 'eigen'
[ 27%] Built target eigen

[unfa]

Another error. I will build again in single-thread mode to try and find what is the issue.
There's definitely a problem that my system-provided CMake version is too new, and build files are made for version 3.5 - I see errors about that):

-- Configuring incomplete, errors occurred!
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

Not sure what can I do about that...

[unfa]

Ok, single-threaded build fails on turbojpeg:

[ 23%] Built target png
[ 23%] Creating directories for 'turbojpeg'
[ 23%] Performing download step (download, verify and extract) for 'turbojpeg'
-- Downloading...
   dst='/data/Software/Meshroom/AliceVision/build/external/download/turbojpeg/2.1.5.1.tar.gz'
   timeout='none'
   inactivity timeout='none'
-- Using src='https://github.com/libjpeg-turbo/libjpeg-turbo/archive/2.1.5.1.tar.gz'
-- verifying file...
       file='/data/Software/Meshroom/AliceVision/build/external/download/turbojpeg/2.1.5.1.tar.gz'
-- Downloading... done
-- extracting...
     src='/data/Software/Meshroom/AliceVision/build/external/download/turbojpeg/2.1.5.1.tar.gz'
     dst='/data/Software/Meshroom/AliceVision/build/external/src/turbojpeg'
-- extracting... [tar xf]
-- extracting... [analysis]
-- extracting... [rename]
-- extracting... [clean up]
-- extracting... done
[ 24%] No update step for 'turbojpeg'
[ 24%] No patch step for 'turbojpeg'
[ 24%] Performing configure step for 'turbojpeg'
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!
make[2]: *** [CMakeFiles/turbojpeg.dir/build.make:93: external/src/turbojpeg-stamp/turbojpeg-configure] Error 1
make[1]: *** [CMakeFiles/Makefile2:493: CMakeFiles/turbojpeg.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

[SFN-eu]

If I remember correctly turbojpeg doesn't have any problems on arch, so you should be able to get away with the system package:
pacman -S libjpeg-turbo

and then add -DAV_BUILD_JPEG=off to the compile flags

[philippremy]

The short explanation

You are using CMake 4.X, which AliceVision currently does not support :D when building embedded dependencies. The workaround (if the package manager provided TurboJPEG does not work) is to use a CMake >= 3.30 but < 4.0 if you can install specific versions.
Again, something that the team probably is aware of and which at some point hopefully be fixed. IIRC you might run into similar problems when building an embedded flann, but I am not sure.

(The longer explanation)

The project depends on many different libraries and some are just not well/not at all maintained (see flann for example, the last commit was 4(!) years ago). And while CMake usually handles such old projects accordingly, they just introduced a big change with CMake 4.0, essentially removing compatibility with all projects that still support pre-3.5. policies.
I plan to eventually rewrite the whole build system from scratch to bring it up to the latest standards and make it less brittle... but this will definitely take a while, because the dependency management is an absolute nightmare. So while I hope that some of these compatibilty issues can be addressed at some point, it'll always be a complex project ._.

[cmkd]

I've been trying to build the development branch on Linux for some days now to test PR #2077, but I keep running into barriers all the time.

Currently, I believe that trying to build this in Docker using the same image that CI also uses is the most promising approach.

I would be grateful if anyone could explain to me why the following approach does not result in successful compilation. If any questions arise, I can also provide more details about the configuration steps I have taken.

Building in the alicevision-deps container

• All of the required dependencies are already included, except for AdaptiveCpp (this might need to change in the future to account for the new backend in automated testing)
  • Building AdaptiveCpp is relatively straightforward because CUDA is already installed
  • For AMD support I also installed the ROCm toolchain which got detected automatically
  • Setting the installation directory to /opt/adaptivecpp made cmake auto-detect it as a provider for SYCL
    Here, I'm running into a major problem that I haven't been able to solve yet. Any help would be greatly appreciated.
    After configuring the project using cmake like this (stolen from the CI workflow):

cmake .. -DCMAKE_BUILD_TYPE=${BUILD_TYPE} \
-DBUILD_SHARED_LIBS=ON \
-DCMAKE_PREFIX_PATH:PATH="${DEPS_INSTALL_DIR}" \
-DCMAKE_INSTALL_PREFIX:PATH="${ALICEVISION_ROOT}" \
-DALICEVISION_BUNDLE_PREFIX:PATH="${ALICEVISION_BUNDLE}" \
-DTARGET_ARCHITECTURE=core \
-DALICEVISION_BUILD_TESTS=ON \
-DALICEVISION_BUILD_SWIG_BINDING=ON \
-DALICEVISION_USE_OPENCV=ON \
-DALICEVISION_USE_CUDA=OFF \
-DALICEVISION_USE_SYCL=ON \
-DALICEVISION_USE_CCTAG=ON \
-DALICEVISION_USE_POPSIFT=ON \
-DALICEVISION_USE_ALEMBIC=ON \
-DALICEVISION_USE_USD=ON \
-DOpenCV_DIR:PATH="${DEPS_INSTALL_DIR}/share/OpenCV" \
-DCeres_DIR:PATH="${DEPS_INSTALL_DIR}/share/Ceres" \
-DAlembic_DIR:PATH="${DEPS_INSTALL_DIR}/lib/cmake/Alembic" \
-DSWIG_DIR:PATH="${DEPS_INSTALL_DIR}/share/swig/4.3.0" \
-DSWIG_EXECUTABLE:PATH="${DEPS_INSTALL_DIR}/bin-deps/swig" \
-DPython3_EXECUTABLE:PATH=/usr/bin/python

and building using either make or ninja, compilation stops when trying to build the new backend:

[ 65%] Building CXX object src/aliceVision/depthMap_sycl/CMakeFiles/aliceVision_depthMap_sycl.dir/computeOnMultiDevices.cpp.o
clang-20: error: unknown argument: '-mno-avx5124fmaps'
clang-20: error: unknown argument: '-mno-avx5124vnniw'
clang-20: error: unknown argument: '-mno-avx512er'
clang-20: error: unknown argument '-mno-avx512pf'; did you mean '-mno-avx512f'?
clang-20: error: unknown argument: '-mno-prefetchwt1'
clang-20: error: unknown argument '-mno-abm'; did you mean '-mno-tbm'?
clang-20: warning: the flag '-mno-mpx' has been deprecated and will be ignored [-Wunused-command-line-argument]
make[2]: *** [src/aliceVision/depthMap_sycl/CMakeFiles/aliceVision_depthMap_sycl.dir/build.make:81: src/aliceVision/depthMap_sycl/CMakeFiles/aliceVision_depthMap_sycl.dir/computeOnMultiDevices.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:9706: src/aliceVision/depthMap_sycl/CMakeFiles/aliceVision_depthMap_sycl.dir/all] Error 2

I am using the preinstalled version of gcc12 from the container for compilation (this gets picked up correctly by cmake during configuration).
Did I do something wrong by doing so? I cannot get the rest of the project to build when using clang to compile the entire project.
My understanding of what is happening here is that AdaptiveCpp uses its own included Clang to do its part of compilation, but because the rest of the build is configured to use GCC it gets passed arguments for the wrong compiler by CMake.
Because I don't have any experience with CMake, I am not capable of editing the corresponding configuration file to see if anything changes, which is why I am writing this comment to ask for help.

Using Clang for compilation

Would building the entire project using Clang be an option? If it is: what would I have to change about my configuration so the rest of the project builds without errors using Clang?
Currently, when using this for setup (setting compilers to Clang 20):

cmake .. -DCMAKE_BUILD_TYPE=${BUILD_TYPE} \
-DBUILD_SHARED_LIBS=ON \
-DCMAKE_PREFIX_PATH:PATH="${DEPS_INSTALL_DIR}" \
-DCMAKE_INSTALL_PREFIX:PATH="${ALICEVISION_ROOT}" \
-DALICEVISION_BUNDLE_PREFIX:PATH="${ALICEVISION_BUNDLE}" \
-DTARGET_ARCHITECTURE=core \
-DALICEVISION_BUILD_TESTS=ON \
-DALICEVISION_BUILD_SWIG_BINDING=ON \
-DALICEVISION_USE_OPENCV=ON \
-DALICEVISION_USE_CUDA=OFF \
-DALICEVISION_USE_SYCL=ON \
-DALICEVISION_USE_CCTAG=ON \
-DALICEVISION_USE_POPSIFT=ON \
-DALICEVISION_USE_ALEMBIC=ON \
-DALICEVISION_USE_USD=ON \
-DOpenCV_DIR:PATH="${DEPS_INSTALL_DIR}/share/OpenCV" \
-DCeres_DIR:PATH="${DEPS_INSTALL_DIR}/share/Ceres" \
-DAlembic_DIR:PATH="${DEPS_INSTALL_DIR}/lib/cmake/Alembic" \
-DSWIG_DIR:PATH="${DEPS_INSTALL_DIR}/share/swig/4.3.0" \
-DSWIG_EXECUTABLE:PATH="${DEPS_INSTALL_DIR}/bin-deps/swig" \
-DPython3_EXECUTABLE:PATH=/usr/bin/python \
-DCMAKE_C_COMPILER=clang-20 \
-DCMAKE_CXX_COMPILER=clang++-20

I get multiple error messages, the first of which is

[  4%] Building CXX object src/aliceVision/image/CMakeFiles/aliceVision_image.dir/colorspace.cpp.o
In file included from /tmp/AliceVision_build/AliceVision/src/aliceVision/image/colorspace.cpp:7:
In file included from /tmp/AliceVision_build/AliceVision/src/aliceVision/image/colorspace.hpp:13:
In file included from /opt/AliceVision_install/include/OpenImageIO/color.h:10:
In file included from /opt/AliceVision_install/include/OpenImageIO/fmath.h:41:
In file included from /opt/AliceVision_install/include/OpenImageIO/span.h:20:
In file included from /opt/AliceVision_install/include/OpenImageIO/detail/fmt.h:67:
In file included from /opt/AliceVision_install/include/OpenImageIO/detail/fmt/format.h:4530:
/opt/AliceVision_install/include/OpenImageIO/detail/fmt/format-inl.h:61:24: error: call to consteval function 'fmt::basic_format_string<char, fmt::basic_string_view<char> &, const char (&)[3]>::basic_format_string<FMT_COMPILE_STRING, 0>' is not a constant expression

I have also tried building with older versions of Clang, but they fail due to incompatibilities with OpenMP. I currently do not have the exact error messages to quote here, but would probably be able to reproduce them should this be a viable strategy.

---

Appendix: Building on Arch Linux

In the process I have also made some discoveries about building on Arch Linux that I wanted to share here so others can benefit from what I've learned. First of, here are all of the workarounds I used to get at least most of the dependencies working:

• Many dependencies of common Arch packages interfere with this build, so I think it might only be possible to build this from a clean chroot
• zlib-ng will interfere with the build, even in the chroot, because it cannot be uninstalled without completely breaking your system (uninstalling Pacman etc.). You will have to use the system provided minizip-ng package instead of building it as a dependency
• cmake<4 can be installed from the Arch Linux Archive
• The system provided texinfo package is too new to build ffmpeg so you need to downgrade it from the archive as well (version 7.1.1 should work)
• gcc12 should work best for building all of the dependencies (some of them, e.g. yaml-cpp depend on the behaviors of older C standards and will not build with a current version of gcc)
  • This can also be installed from the archive, but you have to make sure to install gcc12-libs first as a dependency
    • Just installing the gcc package from the archive with a lower version number will interfere with your system gcc installation so make sure to install gcc12 which provides a binary with a non-interfering name
• python313 can be installed from the AUR and should not take long to build
  • I opted to use a virtual environment to make sure the correct version of python is used for the build

Even applying all of these workarounds, I was not able to build all dependencies on Arch Linux, because xerces-c uses the icu package for Unicode support which is too new to be compatible. Downgrading icu is not possible, because it's a transitive dependency of pacman, so downgrading would probably break the system.
All of this leads me to believe that building this project while also building all of its dependencies is currently not possible on Arch Linux.

[SFN-eu]

A few things:

• The cmake build system is rather temperamental at the moment, this makes building from source an unfortunately frustrating experience at the moment. See philippremy's appendix
  • In general, I found trying to build all dependencies with the build system very temperamental; my experience was that it was much easier to build each bit individually and then link afterwords.
• PR [MVS] Porting CUDA algorithms to SYCL #2077 was developed on Arch Linux, building most of AliceVision with gcc and the SYCL bits with acpp/clang. The way I managed to do this is to not build any dependencies in tree, and instead patch the relatively few bits that don't work with the newer versions provided by system repositories or the AUR.
  • These patches can be found in the AUR package, which also has support for building the SYCL backend https://aur.archlinux.org/packages/alice-vision
  • Using system or AUR packages where possible avoids a world of pain, e.g. your issues with building ffmpeg

[philippremy]

Hi. A quick take from me on this:

The first issue seems to be related to the project's OptimizeForArchitecture functionality. You can pass -DTARGET_ARCHITECTURE=none on the CMake CLI to turn it off (-DTARGET_ARCHITECTURE=native might work as well). Expect the resulting binaries to be slower with none.
The second issue is a known bug in OpenImageIO/fmt, which has already been fixed upstream. You can try increasing the OpenImageIO version in DependencyVersions.cmake to the latest 3.0.X version available (the hash must also be adapted!), maybe it helps.

And I know I start to sound like a spinning wheel, but this is not a beginner's project when building from source. We know about the issues and I am certain everyone involved would like a better solution to this, but sadly it is just not that simple. C++ dependency managment is complex and compiling/linking is very different between architectures, platforms and toolchains. CMake eases some of this, but if a third-party dependency decides to do something funny (they all do and so do we probably), there is nothing we can easily do about that. I am currently working on improving the build system for AliceVision, but I haven't even reached the AliceVision source code yet! I am still finding myself patching various third-party projects to make them somewhat reliable when it comes to cross-platform builds (i.e., I have a long document of various compiler/linker errors I am currently working through). So yes, as @SFN-eu pointed out, it is complex, it is temperamental. So IMHO you have two options:

1. Wait for an official release with pre-built binaries (this is probably not so far away once we figure out how to properly integrate AdaptiveCpp into the CI)
2. Be ready to dig into the project's (and potentially third-party project's) build system code to manually apply fixes needed for your environment. This may take a while (I can tell from experience). You'll have to bring some more advanced knowledge about compilers and linkers with you though, but this might get way easier because AI has gotten pretty good at explaining specific issues.

If you'd ask me, I would strongly suggest option 1 if you just want to use it. Otherwise the maintainers are probably more than happy if people provide pull requests to fix build issues :D. Sometimes a solution is only a grep or a GitHub Search away. But there is only so much help we can provide, sadly.

[cmkd]

Thank you both for your quick and detailed replies. I understand that the build system is hard to deal with for beginners at the moment and I hope that I did not waste your time by writing so much about what I was trying to do. I was under the impression that building the project with the new backend was untested on Arch Linux as of now, that's why I was trying to document the process here.
Thank you @SFN-eu for pointing me to the updated AUR package, I think I will try that next and if it doesn't work I will just wait for an official release.
Also thank you @philippremy for explaining what caused my build issues and providing possible fixes.

But there is only so much help we can provide, sadly.

Of course, I just wanted to get a quick feedback on whether I am approaching building this correctly at all, because I spent way too much time already. I am grateful for your advice and I will probably just wait if I don't get it working on my own soon.