-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
AVX2 makes PCL crash #5806
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
Comments
@Vakarian15 can you try find the configure log file from VCPKG build of PCL - maybe we can see something in the log, whether PCL was build with AVX support or not. |
@larshg Thank you for your swift response. Here is the configure log |
That was the cmake cache and yes, the variable you refer to, is that it should test for AVX(2), but I can't find any "HAVE_AVX" or the like. I was requesting the configuration output when running cmake. Its example from the azure pipline, but hopefully you can find similiar :-) |
I can find |
Here are the files |
Ahh, vcpkg have a patch for SSE https://github.com/microsoft/vcpkg/blob/master/ports/pcl/fix-check-sse.patch But not for AVX and they don't parse default CXX settings, so it will never check for AVX instructions. |
I see, thanks for your time! |
I made a patch for AVX |
And you have enabled AVX in your project as well as copied new dlls etc? |
Yes, I even copied the whole vcpkg\installed\x64-windows\bin folder. |
I was able to get AVX2 to work by using only custom point types with |
I find it funny that there are two connected issues so close together. I think #5805 is the problem. PCL is using |
Hi, thank you for your suggestions, but I tested and I see no reason to assume that
Same as Lars, I think the problem is likely that vcpkg built PCL without AVX/AVX2, so the precompiled classes use a "vanilla" malloc instead of Eigen's custom aligned malloc. When the user code is compiled with AVX/AVX2, Eigen's aligned_free is used (not a "vanilla" free). The mismatch between the "vanilla" malloc and Eigen's aligned_free causes the problem. When using |
As another data point, I encountered this bug on Linux with installing PCL binaries from apt, so it isn't just vcpkg. I haven't tried using the built-in |
The current tutorial (https://pcl.readthedocs.io/projects/tutorials/en/master/using_pcl_pcl_config.html / pcl-1.15.0-rc1) advices to use:
In my tests on Ubuntu, Moreover, AVX flags are only added to Lines 449 to 454 in 46f15a6
It looks like only with MSVC we have SSE flags added to Lines 212 to 231 in 46f15a6
And thus Lines 15 to 17 in 46f15a6
Regarding the possible Eigen alignment issue: pcl/common/include/pcl/memory.h Lines 55 to 75 in 46f15a6
I think Lines 198 to 205 in 46f15a6
This means that on recent x86 architectures, |
@s-trinh in newer versions, the PCL_DEFINITIONS and PCL_COMPILE_OPTIONS is actually not really required anymore. If you print the variables for a given cmake target, ie. pcl_common you get this list:
Hence all the required flags are added, if you just use: Cmake code for printing target properties can be found here. The above is on windows.
I don't think this is set anywhere explicitly in PCL. In what you refer to, its only mentioned in comments. |
Thanks for your answer. This is what I have on Ubuntu/Linux:
-- DOXYGEN_FOUND
-- HTML_HELP_COMPILER
-- Found CPack generators: DEB
-- PCL build with following flags:
-- -Wabi=18 -Wall -Wextra -fno-strict-aliasing -msse4.2 -mfpmath=sse -march=native -mavx2 -fopenmp
-- The following subsystems will be built:
-- common
## https://stackoverflow.com/questions/32183975/how-to-print-all-the-properties-of-a-target-in-cmake/56738858#56738858
## https://stackoverflow.com/a/56738858/3743145
## Get all properties that cmake supports
execute_process(COMMAND cmake --help-property-list OUTPUT_VARIABLE CMAKE_PROPERTY_LIST)
## Convert command output into a CMake list
STRING(REGEX REPLACE ";" "\\\\;" CMAKE_PROPERTY_LIST "${CMAKE_PROPERTY_LIST}")
STRING(REGEX REPLACE "\n" ";" CMAKE_PROPERTY_LIST "${CMAKE_PROPERTY_LIST}")
list(REMOVE_DUPLICATES CMAKE_PROPERTY_LIST)
function(print_target_properties tgt)
if(NOT TARGET ${tgt})
message("There is no target named '${tgt}'")
return()
endif()
foreach (prop ${CMAKE_PROPERTY_LIST})
string(REPLACE "<CONFIG>" "${CMAKE_BUILD_TYPE}" prop ${prop})
get_target_property(propval ${tgt} ${prop})
if (propval)
message ("${tgt} ${prop} = ${propval}")
endif()
endforeach(prop)
endfunction(print_target_properties)
print_target_properties(pcl_common) gives: pcl_common BINARY_DIR = [...]/pcl-example-TMP/build
pcl_common IMPORTED = TRUE
pcl_common IMPORTED_CONFIGURATIONS = RELEASE;DEBUG
pcl_common INTERFACE_COMPILE_FEATURES = cxx_std_17
pcl_common INTERFACE_COMPILE_OPTIONS = $<$<COMPILE_LANGUAGE:CXX>:-msse4.2;-mfpmath=sse;-march=native;-mavx2>
pcl_common INTERFACE_INCLUDE_DIRECTORIES =
/usr/include/eigen3;[...]/pcl-build-TMP/install/include/pcl-1.15;[...]/pcl-build-TMP/install/include/pcl-1.15
pcl_common INTERFACE_LINK_LIBRARIES = Eigen3::Eigen;Boost::system;Boost::iostreams;Boost::filesystem;Boost::serialization
pcl_common LOCATION = [...]/pcl-build-TMP/install/lib/libpcl_common.so
pcl_common LOCATION_Release = [...]/pcl-build-TMP/install/lib/libpcl_common.so
pcl_common MACOSX_PACKAGE_LOCATION = [...]/pcl-build-TMP/install/lib/libpcl_common.so
pcl_common NAME = pcl_common
pcl_common POSITION_INDEPENDENT_CODE = True
pcl_common SOURCE_DIR = [...]/pcl-example-TMP
pcl_common SYSTEM = ON
pcl_common TYPE = SHARED_LIBRARY
pcl_common VS_DEPLOYMENT_LOCATION = [...]/pcl-build-TMP/install/lib/libpcl_common.so
gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
/usr/libexec/gcc/x86_64-linux-gnu/13/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw
[...] Ultimately, using |
@s-trinh Linking to |
@mvieth
Regardless of CMake, to be sure, if PCL is built with optimizations for AVX512 for a CPU with AVX512, it is thus necessary in the user code to have 64 bytes alignment for Eigen objects. The quoted phrase is ambiguous to me. |
- Instead of using PCL_COMPILE_OPTIONS cmake var, we are using INTERFACE_COMPILE_OPTIONS property over pcl components to build an internal var named PCL_DEPS_COMPILE_OPTIONS - This new strategy is the one recommended in PointCloudLibrary/pcl#5806 - We recall that propagating pcl compile option is requested to avoid Potential runtime error due to aligned malloc mismatch! See lagadic#1681
Closing as its not a bug in PCL per se. But rather a configuration issue thats not aligned between PCL build libraries and user code. There have been added various checks and documentation on how to correctly handle this. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
I am trying to downsample a
pcl::PointXYZRGBNormal
PointCloud using aVoxelGrid
filter.AVX2 makes my program crash, I tried it with 1.12.0 and 1.13.1, both of them have the same problem.
To Reproduce
If I disable AVX2, it works. If I replace
pcl::PointCloud<pcl::PointXYZRGBNormal>
withpcl::PCLPointCloud2
, it works. So I'm not sure it is a problem ofpcl::PointXYZRGBNormal
orpcl::VoxelGrid
.Here is the sample project including the dataset: PCLTest.zip
Screenshots/Code snippets

Stack track
Your Environment (please complete the following information):
Additional context
In 1.13.1, both
pcl::PointXYZRGBNormal
andpcl::VoxelGrid
havePCL_MAKE_ALIGNED_OPERATOR_NEW
macro. So I have no idea what the problem is. Thanks in advance.The text was updated successfully, but these errors were encountered: