[gdal-dev] Re: OpenCL, GDAL, and You

[Even Rouault]

Le vendredi 17 décembre 2010 23:41:53, Seth Price a écrit :
> I'm working on the trunk OpenCL build on my Mac now.
> 
> ****** First, on my mac I get an error at the end of make:
> [...] ./ogr/.libs/ogr_srs_xml.o ./ogr/.libs/ograssemblepolygon.o ./
> ogr/.libs/ogr2gmlgeometry.o ./ogr/.libs/gml2ogrgeometry.o ./ogr/.libs/
> ogr_expat.o   /opt/local/lib/libsqlite3.dylib -L/opt/local/lib -L/usr/
> local/lib /usr/local/lib/libexpat.dylib /usr/local/lib/libjpeg.dylib /
> usr/local/lib/libtiff.dylib /usr/local/lib/libpng12.dylib -lpthread -
> ldl /opt/local/lib/libcurl.dylib /opt/local/lib/libidn.dylib -lssl -
> lcrypto -lz -lOpenCL    -install_name  /usr/local/lib/libgdal.1.dylib -
> compatibility_version 16 -current_version 16.0 -Wl,-single_module
> ld: library not found for -lOpenCL
> collect2: ld returned 1 exit status
> make[1]: *** [libgdal.la] Error 1
> make: *** [check-lib] Error 2
> seth:gdal-svn-trunk-2010.12.17 sprice$
> 
> To fix this, I changed "OPENCL_LIB      =       -lOpenCL" to
> "OPENCL_LIB      =       -framework OpenCL" in GDALMmake.opt.

I can't help for MacOS build system.

> 
> *****  Why is USE_CLAMP_TO_DST_FLOAT in there? I would think that is
> required even if it isn't on ATI. I'm not sure who inserted its use,
> but I'm just wondering if the reasoning is documented somewhere.

It's me. You can find the culprit of any commit by doing a svn blame or looking 
at the log ;-)

The reasoning was that I observed with my ATI card that float buffers didn't get 
to be multiplied by FLT_MAX. The values weren't normalized between 0 and 1, 
but had directly the expected value. (in the float case, I also dropped the 
rounding to nearest integer which is clearly not desired, and not in the CPU 
implementation)

This is perhaps also needed for NVidia, but I have no way to check, so I just 
put the condition you saw. If you can check this is unneeded, the condition 
can go away.

> 
> ***** I had to make this change to alg/gdalwarpkernel_opencl.c to get
> it to build without a build option error.
> 
> @@ -1168,7 +1168,7 @@
> 
>       //Assemble the compiler arg string for speed. All invariants
> should be defined here.
>       sprintf(buffer, "-cl-fast-relaxed-math -Werror -D FALSE=0 -D
> TRUE=1 "
> -            "%s "
> +            "%s"
>               "-D iSrcWidth=%d -D iSrcHeight=%d -D iDstWidth=%d -D
> iDstHeight=%d "
>               "-D useUnifiedSrcDensity=%d -D useUnifiedSrcValid=%d "
>               "-D useDstDensity=%d -D useDstValid=%d -D useImag=%d "
> @@ -1176,9 +1176,9 @@
>               "-D nXRadius=%d -D nYRadius=%d -D nFiltInitX=%d -D
> nFiltInitY=%d "
>               "-D PI=%015.15lff -D outType=%s -D dstMinVal=%015.15lff -
> D dstMaxVal=%015.15lff "
>               "-D useDstNoDataReal=%d -D vecf=%s %s -D doCubicSpline=
> %d "
> -            "-D useUseBandSrcValid=%d -D iCoordMult=%d",
> +            "-D useUseBandSrcValid=%d -D iCoordMult=%d ",
>               /* FIXME: Is it really a ATI specific thing ? */
> -            (warper->imageFormat == CL_FLOAT && warper->bIsATI) ? "-D
> USE_CLAMP_TO_DST_FLOAT=1" : "",
> +            (warper->imageFormat == CL_FLOAT && warper->bIsATI) ? "-D
> USE_CLAMP_TO_DST_FLOAT=1 " : "",
>               warper->srcWidth, warper->srcHeight, warper->dstWidth,
> warper->dstHeight,
>               warper->useUnifiedSrcDensity, warper->useUnifiedSrcValid,
>               warper->useDstDensity, warper->useDstValid, warper-
> 
>  >imagWorkCL != NULL,

Which error did you get ? You are just changing some whitespace change that 
seem to be equivalent to the trunk code. Or do I miss something ?

> 
> **** After doing all of the above to make things compile, I don't get
> the bug described below. I'm working off of the latest trunk daily.

Yeah, that's probably an issue with the ATI SDK.

> 
> ~Seth
> 
> On Dec 8, 2010, at 1:12 PM, Even Rouault wrote:
> > Seth,
> > 
> > Thanks for your help.
> > 
> >> It's more than a little strange that none of those image sizes work.
> >> Perhaps it's a problem with the image format? Can you verify that the
> >> given format should work?
> > 
> > The image format was CL_UNORM_INT8 (for GDT_Byte)
> > 
> >> Looking at the spec, it might also be a problem with the 'sz'
> >> argument. What value is that passing?
> > 
> > It's 1.
> > 
> > I managed to found the following workaround that enables gdalwarp to
> > complete
> > (see http://trac.osgeo.org/gdal/changeset/21220  that basically
> > passes a dummy
> > buffer instead of a NULL pointer).
> > 
> > However the visual result of the warping is really poor. I see 4
> > "ghost"
> > images shifted.
> > 
> > For better understanding I've attached the source image
> > (small_world_b1.tif)
> > and the result of bilinear resampling (but I get similar weird
> > visual effects
> > with cubic, cubic spline or lanczos)
> > 
> > gdalwarp  -rb small_world_b1.tif out_bilinear.tif
> > 
> > Best regards,
> > 
> > Even
> > <small_world_b1.tif><out_bilinear.tif>