<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
Gave this a try on Windows (relatively simple to build) with CUDA
and indeed the difference in speed is big.<br>
Petty that the result is quite broken.<br>
<br>
My test was with this projection<br>
<br>
gdalwarp -t_srs +proj=sinu mundo.tiff lixo32.tiff<br>
<br>
<br>
Joaquim<br>
<br>
<blockquote
cite="mid:9B194ACD-4936-43A7-8638-A16E684EAF93@pricepages.org"
type="cite">
<div>I'm working on the trunk OpenCL build on my Mac now.</div>
<div><br>
</div>
<div>****** First, on my mac I get an error at the end of make:</div>
<div>[...] ./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</div>
<div>
<div>ld: library not found for -lOpenCL</div>
<div>collect2: ld returned 1 exit status</div>
<div>make[1]: *** [libgdal.la] Error 1</div>
<div>make: *** [check-lib] Error 2</div>
<div>seth:gdal-svn-trunk-2010.12.17 sprice$</div>
</div>
<div><br>
</div>
<div>To fix this, I changed "OPENCL_LIB = -lOpenCL" to
"OPENCL_LIB = -framework OpenCL" in GDALMmake.opt.</div>
<div><br>
</div>
<div>***** Why is <span class="Apple-style-span" style="color:
rgb(196, 26, 22); font-family: Monaco; font-size: 10px;">USE_CLAMP_TO_DST_FLOAT</span> 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.</div>
<div><br>
</div>
<div>***** I had to make this change
to alg/gdalwarpkernel_opencl.c to get it to build without a
build option error.</div>
<div><br>
</div>
<div>
<div>@@ -1168,7 +1168,7 @@</div>
<div> </div>
<div> //Assemble the compiler arg string for speed. All
invariants should be defined here.</div>
<div> sprintf(buffer, "-cl-fast-relaxed-math -Werror -D
FALSE=0 -D TRUE=1 "</div>
<div>- "%s "</div>
<div>+ "%s"</div>
<div> "-D iSrcWidth=%d -D iSrcHeight=%d -D
iDstWidth=%d -D iDstHeight=%d "</div>
<div> "-D useUnifiedSrcDensity=%d -D
useUnifiedSrcValid=%d "</div>
<div> "-D useDstDensity=%d -D useDstValid=%d -D
useImag=%d "</div>
<div>@@ -1176,9 +1176,9 @@</div>
<div> "-D nXRadius=%d -D nYRadius=%d -D
nFiltInitX=%d -D nFiltInitY=%d "</div>
<div> "-D PI=%015.15lff -D outType=%s -D
dstMinVal=%015.15lff -D dstMaxVal=%015.15lff "</div>
<div> "-D useDstNoDataReal=%d -D vecf=%s %s -D
doCubicSpline=%d "</div>
<div>- "-D useUseBandSrcValid=%d -D iCoordMult=%d",</div>
<div>+ "-D useUseBandSrcValid=%d -D iCoordMult=%d ",</div>
<div> /* FIXME: Is it really a ATI specific thing ?
*/</div>
<div>- (warper->imageFormat == CL_FLOAT &&
warper->bIsATI) ? "-D USE_CLAMP_TO_DST_FLOAT=1" : "",</div>
<div>+ (warper->imageFormat == CL_FLOAT &&
warper->bIsATI) ? "-D USE_CLAMP_TO_DST_FLOAT=1 " : "",</div>
<div> warper->srcWidth, warper->srcHeight,
warper->dstWidth, warper->dstHeight,</div>
<div> warper->useUnifiedSrcDensity,
warper->useUnifiedSrcValid,</div>
<div> warper->useDstDensity,
warper->useDstValid, warper->imagWorkCL != NULL,</div>
</div>
<div><br>
</div>
<div>**** 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.</div>
<div><br>
</div>
<div>~Seth</div>
<div><br>
</div>
<br>
<div>
<div>On Dec 8, 2010, at 1:12 PM, Even Rouault wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>Seth,<br>
<br>
Thanks for your help.<br>
<br>
<blockquote type="cite">It's more than a little strange that
none of those image sizes work.<br>
</blockquote>
<blockquote type="cite">Perhaps it's a problem with the
image format? Can you verify that the<br>
</blockquote>
<blockquote type="cite">given format should work?<br>
</blockquote>
<br>
The image format was CL_UNORM_INT8 (for GDT_Byte)<br>
<br>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Looking at the spec, it might also
be a problem with the 'sz'<br>
</blockquote>
<blockquote type="cite">argument. What value is that
passing?<br>
</blockquote>
<br>
It's 1.<br>
<br>
I managed to found the following workaround that enables
gdalwarp to complete <br>
(see <a moz-do-not-send="true"
href="http://trac.osgeo.org/gdal/changeset/21220">http://trac.osgeo.org/gdal/changeset/21220</a>
that basically passes a dummy <br>
buffer instead of a NULL pointer).<br>
<br>
However the visual result of the warping is really poor. I
see 4 "ghost" <br>
images shifted.<br>
<br>
For better understanding I've attached the source image
(small_world_b1.tif) <br>
and the result of bilinear resampling (but I get similar
weird visual effects <br>
with cubic, cubic spline or lanczos)<br>
<br>
gdalwarp -rb small_world_b1.tif out_bilinear.tif<br>
<br>
Best regards,<br>
<br>
Even<br>
<span><small_world_b1.tif></span><span><out_bilinear.tif></span></div>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></pre>
</blockquote>
<br>
</body>
</html>