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

Seth Price seth at pricepages.org
Fri Dec 17 17:41:53 EST 2010


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.

*****  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.

***** 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,

**** 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.

~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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101217/ab11cb59/attachment.html


More information about the gdal-dev mailing list