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