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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
