Vision: warning: ignoring #pragma omp parallel

[xkszltl]

🐛 Bug

I'm seeing a lot of warning: ignoring #pragma omp parallel like this:

Maybe there should be a -fopenmp?

Environment

• PyTorch / torchvision Version (e.g., 1.0 / 0.4.0): master/master
• OS (e.g., Linux): Ubuntu 18.04
• How you installed PyTorch / torchvision (conda, pip, source): source
• Build command you used (if compiling from source): cmake+ninja+gcc-8
• Python version: 3.6
• CUDA/cuDNN version: 11.0/8

[fmassa]

Thanks for the report. We don't directly use omp parallel in nms_cpu, so this might be somewhere else.

We will have a look.

[xkszltl]

@vfdev-5 Any news so far?

[vfdev-5]

@xkszltl i'll try to take a look at this issue this week.

[klvnptr]

@vfdev-5 any update? :) I'm having the same problem

[vfdev-5]

@klvnptr Sorry, seems like I missed this issue in my task list. Let me check this on monday. Thanks.

[klvnptr]

thanks for getting back @vfdev-5
for me this solved the problem:
$ apt-get install libopenmpi-dev
$ CFLAGS="-fopenmp" python3 setup.py bdist_wheel

[xkszltl]

@vfdev-5
I don't think that's the right way.

• It should be done in CMake, not setup.py, or the issue is still there when calling cmake directly.
• When adding openmp, you should use find_package(OpenMP) and link to it.
• Blindly adding -fopenmp may cause inconsistent result with pytorch's openmp. There're many openmp implementations, not just the default one.
• This could be an issue in pytorch where it doesn't expose openmp flag in dependency properly. If so issue should be forwarded to them as well.

[xkszltl]

Bring up issue in upstream as well: https://github.com/pytorch/pytorch/issues/48033

[vfdev-5]

@xkszltl the warning warning: ignoring #pragma omp parallel is seen when we build torchvision with python setup.py build and more precisely when C++ extensions are built:
https://github.com/pytorch/vision/blob/74de51d6d478e289135d9274e6af550a9bfba137/setup.py#L423

As far as I understand this process, there is no CMake associated with that.

Blindly adding -fopenmp may cause inconsistent result with pytorch's openmp. There're many openmp implementations, not just the default one.

Could you please detail this point.

When adding openmp, you should use find_package(OpenMP) and link to it.

Maybe, this has to be addressed separately for C++ frontend... We have to investigate that.

[xkszltl]

@vfdev-5
You're right, it only shows up in pip build, not pure cmake build.
Didn't notice that before.

Could you please detail this point.

That could be -fopenmp-simd; could be choices of iomp/gomp; could be iomp from llvm or from intel; or even a mix of these.
OpenMP can have many incompatible configurations.

[fmassa]

@xkszltl do you think we should we revert #3006 due to potential conflicts with the OpenMP used by PyTorch?

[xkszltl]

Once fixed in pytorch, it should definitely be reverted.

Before that, it could be either kept as short-term workaround, or could be removed so that at least it's possible to manually provide only the correct flag when there's conflict.
I slightly lean toward the later, but no strong opinion.

[fmassa]

@vfdev-5 I think having the warning for not using openmp (but still working fine in cases where there could be clashes) is better, so I would be ok reverting the PR.

[vfdev-5]

@fmassa sounds good!

[mthrok]

@vfdev-5
You're right, it only shows up in pip build, not pure cmake build.
Didn't notice that before.

Could you please detail this point.

That could be -fopenmp-simd; could be choices of iomp/gomp; could be iomp from llvm or from intel; or even a mix of these.
OpenMP can have many incompatible configurations.

Recently, in torchaudio we realized that compiling against GNU with -fopenmp flag causes segmentation fault. We would love to learn the correct way to link against the version of OpenMP that PyTorch uses.

[xkszltl]

I don't know.
It's also easy to have an accidental mix of intel iomp/gomp when mkl is there.

Technically cmake dependency should handle that properly.