[gdal-dev] Odd problem -- Gdalwarp, OpenCL and interpolation

[Jonathan Williams]

I've verified the incorrect interpolation results on another machine (a
laptop with an nVidia gt-555m GPU).

I'm honestly at a loss as to what is causing this, and hope it's not
something simple. Has anyone run across this before?

Best,
Jonathan

On 3/5/2016 8:54 PM, Jonathan Williams wrote:
> To clarify: doing the gdalwarp resample without OpenCL is producing a
> realistic Float32 value range. Doing it WITH OpenCL is producing far
> higher values.
>
> This is on a Tesla M2090. No other experiments/benchmarks have produced
> this kind of result, and as I wrote below, gdalwarp itself works when
> only doing reprojection, not resampling, regardless of whether OpenCL is
> used.
>
> Jonathan
>
>
> On 3/5/2016 7:06 PM, Jonathan Williams wrote:
>> Hello,
>> I've run into an odd problem that I suspect is the result of some
>> incorrect variable type casting, but I'm not sure where to look or how
>> to fix it.
>>
>> Inputting a raster in Float32 format (or Float64, with -ot Float32
>> and/or -wt Float32 enabled on the command line) and attempting to do a
>> resample interpolation (doesn't seem to matter what OpenCL-compatible
>> algorithm) is producing output that is huge compared with the input. The
>> output still has a range of values, and it makes me wonder whether the
>> output is being multiplied by a very large amount at some point.
>>
>> Saga GIS reports the non-OpenCL resampled Float32 values as ranging from
>> -8.595017433166504 to 166.74661254882812, and the resampled values as
>> ranging from -340282346638528860000000000000000000000 to
>> 340282346638528860000000000000000000000 (+/- 3.4e38, e.g. the maximum
>> range of single precision floating point)
>>
>> Running the exact same warp with OpenCL disabled produces the correct
>> output.
>>
>> Here's an example of the gdalwarp runline:
>>
>> gdalwarp -srcnodata 9999 -dstnodata 9999 -wt Float32 -ot Float32
>> --config GDAL_CACHEMAX 4096 -wm 2048 -multi -tr .03 .03 -r lanczos
>> --debug on -overwrite -wo "USE_OPENCL=TRUE" 373.grib2 373_res.tif
>>
>> I will note that the input file in this case is in Float64 format;
>> however, converting it to Float32 prior to the warp makes no difference.
>> Neither does whether the input file is in grib2 format or geotiff format.
>>
>> Reprojection-only operations produce normal-looking output using OpenCL.
>>
>> Best,
>> Jonathan
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev