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

[Joaquim Luis]

Hi,

Gave this a try on Windows (relatively simple to build) with CUDA and 
indeed the difference in speed is big.
Petty that the result is quite broken.

My test was with this projection

gdalwarp -t_srs +proj=sinu mundo.tiff lixo32.tiff


Joaquim

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101218/7f319e25/attachment-0001.html