I get the same wrong results with and without Docker, with and without the SSE/SSE3/AVX when using the configure script. I also tried removing -O2. Is the SSE3 unpacking in GDAL or in libgeotiff?
On 29/12/2019 21:51, Even Rouault wrote:
Is it possible that this is a compiler issue? Anyone else that can test this on an AMD CPU? Mine are old Phenom II X4 965s.Perhaps rather a runtime issue. I suspect this is related to a SSSE3 optimization that has been added in GDAL 2.2 that is used in this use case (unpacking of byte buffer with a 2 byte stride to packed buffer) From what I found on the net, I think this CPU doesn't support the SSSE3 instruction set (SSSE3 with three S, not to be confused with SSE3...) Can you check the following ? cat /proc/cpuinfo | grep ssse3 What is strange is that GDAL does have a runtime check to detect if SSSE3 is available, so I'm not sure why you would get that issue. Unless that Docker would wrongly expose SSSE3, but Docker is not a VM technology so it shouldn't mess up with CPU capability discoveries. This is weird. Can you try the following ? docker run --rm osgeo/gdal su -c "apt install -y cpuid; cpuid" | grep SSSE3 In a DEBUG build of GDAL, you could disable at runtime the SSSE3 optimization by defining the environment variable/configuration option GDAL_USE_SSSE3 to NO, but this will not work on the release builds available on Docker.
-- Momtchil Momtchev <[email protected]> _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
