[gdal-dev] Different results when reading a GeoTIFF with GDAL 2.1.2 vs 3.x

[Momtchil Momtchev]

     I recompiled with the modified CPU detection, the SSE3 syntax error 
and with the default configure options (after a distclean) and I get the 
_incorrect_ result.


On 29/12/2019 22:15, Momtchil Momtchev wrote:
>
>     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 <momtchil at momtchev.com>