[gdal-dev] GDAL using Nvidia - won't use OpenCL

[Jonathan Williams]

OK, I've solved this one, too, but it took a bit more hunting and
inserting of debug messages...

The issue in this case was the data.  I was using weather data in .grib2
files, which comes in Float64 format. Digging into the
gdalwarpkernel.cpp code, I see it is explicitly designed to only use up
to Float32 with OpenCL. After running the file through GDAL_Translate
first, it now makes use of OpenCL.

By any chance, does anyone know whether current GPU's, with current
OpenCL code, can handle double-precision floating point?  I thought that
was the case.

Anyway, OpenCL problem solved, and with the expected significant speedup.

Best,
Jonathan

On 2/15/2016 1:40 PM, Jonathan Williams wrote:
> Hello,
> I've been trying to compile GDAL with OpenCL support for an Nvidia
> gt555m (this is an Alienware m14x r1 laptop) on Ubuntu desktop (I wanted
> to run it headless, but Ubuntu server failed to boot with the Nvidia
> drivers and without X installed).
>
> Per the instructions at various sites, including here:
> https://wiki.tiker.net/OpenCLHowTo , I installed Ubuntu packages
> nvidia-346, nvidia-346-uvm, nvidia-libopencl1-346 and
> nvidia-opencl-icd-346. Other combinations seemed to fail, including
> adding nvidia-opencl-dev, and more recent Ubuntu Nvidia driver versions
> didn't include the uvm package (I think the current driver is the 361
> series).
>
> So, after installing these packages and making sure everything was in
> order in /etc/OpenCL/vendors, I verified OpenCL was functional using
> test packages like MandelGPU/MandelCPU. The OpenCL speedup was obvious
> using these tests.
>
> After a lot of trial-and-error compilations, this is my configuration
> for GDAL with OpenCL:
>
> ./configure \
> --prefix=/usr \
> --disable-rpath \
> --with-threads=yes \
> --with-ogr \
> --with-geos \
> --without-libtool \
> --with-libz=internal \
> --with-libtiff=internal \
> --with-geotiff=internal \
> --with-pg=/usr/bin/pg_config \
> --with-expat-lib=/usr/lib/x86_64-linux-gnu/libexpat.so \
> --with-netcdf=/usr/lib \
> --with-png=internal \
> --with-jpeg=internal \
> --with-gif=internal \
> --without-kakadu \
> --without-mrsid \
> --without-jp2mrsid \
> --with-liblzma=yes \
> --with-curl=/usr/lib/x86_64-linux-gnu \
> --with-ecw=/usr/local/hexagon \
> --with-python=yes \
> --with-hide-internal-symbols \
> --with-jasper=/usr/local \
> --with-openjpeg=/usr/local \
> --with-opencl=yes \
> --with-opencl-include=/usr/include \
> --with-opencl-lib="-L/usr/lib/x86_64-linux-gnu -lOpenCL"
>
> While I did get a couple of errors with this, they seem unrelated to
> anything important (complaining of a zero-length gnu_printf format
> string, ./config.rpath not existing, and GDALmake.opt.in ignoring the
> --datarootdir setting), and a look at the output indicates OpenCL
> support is selected.
>
> Compilation itself completes with no obvious errors, and the resulting
> functions run correctly. However, there is no speedup from using -wo
> "USE_OPENCL=TRUE" over -wo "USE_OPENCL=FALSE", nor is there any effect
> seen using nvidia-smi monitoring.
>
> The GDALWARP command I'm running is this:
> gdalwarp -srcnodata 9999 -dstnodata 9999 -t_srs EPSG:4326 -of GTiff -tr
> 0.03 0.03 -r cubicspline -multi -wo "USE_OPENCL=TRUE" tmp.grib2 tmp.tif
>
> vs.
>
> gdalwarp -srcnodata 9999 -dstnodata 9999 -t_srs EPSG:4326 -of GTiff -tr
> 0.03 0.03 -r cubicspline -multi -wo "USE_OPENCL=FALSE" tmp.grib2 tmp.tif
>
>
> This system has four cores and is multithreading, so -wo
> "NUM_THREADS=ALL_CPUS" does produce a speedup. But again, USE_OPENCL
> does not. In fact, the program is entirely functional and does exactly
> what I want, except for opencl functionality.
>
> I'm at a bit of a loss as to what might be wrong. I've tried various
> combinations of the with-opencl flags. I'm running all functions as
> root, and have tried modprobe nvidia-uvm. No errors, no debug problems
> noted, it just won't use the GPU. Part of my problem is I'm not sure
> what problems would produce an error, and what just would fail silently.
>
> Any insight would be appreciated!
>
> Best regards,
> Jonathan Williams
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev