[question]FeatureMatching guided matching performance in Clear Linux

[gryan315]

Hi, I've been benchmarking one of my datasets on multiple platforms in 2019.2 binary download. It's a small object with a 35 image dataset, works well without guided matching, but I tick guided matching to stress the CPU usage. For this specific case in question, I am using a dual CPU system with a total of 24 cores. Going from windows 10 to manjaro linux, I saw a 30% reduction in time for guided matching, as well as a 22% reduction in time overall.

After jumping through the hoops required, I managed to get nvidia drivers and cuda working on clear linux (mostly, I'm still missing nvidia-smi). The meshroom direct download binary worked immediately, but when on the guided matching step, half of all available CPU threads were unused. This resulted in a significantly slower result than what I had been seeing in Manjaro. I tracked that particular issue (maybe) down to the Pyside path, because after updating it to the home .local path, htop showed all threads being used with guided matching. This did not increase the performance at all however, and it finished both stages of FeatureMatching in approximately the same amount of time as when it was only using half of the threads.

I would really appreciate any tips on where to start to look to solve this, I'm very new to linux. Clear Linux has gained some significant performance improvements over Manjaro in almost every node except for FeatureMatching, with an 18% faster time in DepthMap, almost 40% faster time in Meshing, and LSCM Texturing finishing in half the time as on Manjaro. Even with these major speed-ups, because of how much longer the guided matching is taking, the overall job time is nearly the same.

[natowi]

That is really interesting. I can not answer your question, but you can try disabling chunks to make full use of the multi core system. (This reduced computation time by ~20% in my case) Feedback on this feature would be appreciated.

[gryan315]

I created a shell script to launch meshroom with MESHROOM_USE_MULTI_CHUNKS=0 and I have no idea if it worked or not (ran exactly the same, nothing different in logs). What is the proper way to enact environment variables in meshroom?

[natowi]

When using the GUI multi chunks are reduced to one. I tried this on windows+gui only.

[gryan315]

So then it certainly did not work by putting that in the shell script to launch the GUI, since it still had 2 chunks on featurematching. Where did you call the variable from?

[fabiencastan]

It's in the develop branch, and not yet in a release.

[natowi]

Sorry, forgot to mention this.

[gryan315]

I wish I knew what I was doing. Every time I try to build meshroom, it never works. This attempt was the fastest it's ever failed though...

CMake Error at /usr/share/cmake-3.16/Modules/ExternalProject.cmake:1708 (message):
dir '/qtoiio_build' does not exist after file(MAKE_DIRECTORY)

[natowi]

I do not use linux so often, but you should be able to run Meshroom without building it.

Read https://github.com/alicevision/meshroom/blob/develop/README.md#get-the-project
and set the paths as described here
https://github.com/alicevision/meshroom/blob/develop/INSTALL.md

You should be able to use the libraries (alicevision, alembic and oiio) from your existing Meshroom linux installation

[gryan315]

You are overestimating my abilities. I do not know where to set these variables. I have no trouble running the python script to open the UI, but it is non-functional.

[natowi]

You need to set the PATH variables before launching the UI #685.

When I have some time I will install linux in my vm and update the Meshroom on Linux guide in the documentation with more details.

[gryan315]

By using the old alicevision binaries, I'm having to go through the python node files and remove arguments that were added to the dev build to get it working.

I just got it working up to FeatureMatching to test that. While it is faster than it was with multiple chunks, it is still slower than my last run on the manjaro distribution.

[gryan315]

Made a bit of progress yesterday, but more confusion. I finally managed to compile alicevision by going through and building each dependency one at a time, then commenting out all the dependencies in the cmake file and running cmake with build_dependencies=on (for some reason running it with off it would find CUDA 10.2, but refuse to acknowledge that it's higher than 7, and running with dependencies on without commenting out all the dependencies, it would always encounter errors on some.)

After too much time troubleshooting and finding workarounds, I have a working alicevision build on Clear Linux, so I ran the dev build of meshroom through a full run off my test set (what file should I be using for the SIFT tree? I could not find a similar file to the .tree file that's included with the binary release, so I ended up using that. Should I be pointing to a file in /usr/local/include/alicevision/voctree?) The overall processing time with single chunk was around 20% faster than my 2019.2 run on this system, but FeatureMatching on guided matching is only using about 50% CPU.

The original problem before I added my .local/bin directory to the path to get pyside working was half the threads on both CPUs were unused, but it was the upper half of both CPUs being completely unutilized. Now with the dev build, overall utilization is around 50%, and watching thread activity on htop shows about half the threads at 100%, but the activity is jumping around, not limited to only specific thread numbers, indicating that all threads are available, but something is preventing them from all being used at once.