<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>I can't help for MacOS build system.<br></div></blockquote></div><div><br></div><div>Good thing I'm here. :) Do you want an account on my machine for testing?</div><div><br></div><div><blockquote type="cite"><div>It's me. You can find the culprit of any commit by doing a svn blame or looking <br>at the log ;-)<br></div></blockquote></div><div><br></div><div>Most of that <span class="Apple-style-span" style="color: rgb(196, 26, 22); font-family: Monaco; font-size: 10px; ">clampToDst()</span> code was brought over from <span class="Apple-style-span" style="color: rgb(0, 116, 0); font-family: Monaco; font-size: 10px; ">GWKSetPixelValue()</span>. I'm not sure if it's a good idea to remove it. The original .cpp file should be the same as the new OpenCL code/. My goal is to make the code execution identical so I don't need to do any post-processing of pixels when I copy them out of OpenCL memory.</div><div><br></div><div><blockquote type="cite"><div>Which error did you get ? You are just changing some whitespace change that <br>seem to be equivalent to the trunk code. Or do I miss something ?</div></blockquote></div><div><br></div><div>I was getting a weird build options error that seems to be caused by an extra space. So you're right that it's a whitespace change, but it's non-trivial.</div><div>~Seth</div><br><div><div>On Dec 17, 2010, at 3:54 PM, Even Rouault wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Le vendredi 17 décembre 2010 23:41:53, Seth Price a écrit :<br><blockquote type="cite">I'm working on the trunk OpenCL build on my Mac now.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">****** First, on my mac I get an error at the end of make:<br></blockquote><blockquote type="cite">[...] ./ogr/.libs/ogr_srs_xml.o ./ogr/.libs/ograssemblepolygon.o ./<br></blockquote><blockquote type="cite">ogr/.libs/ogr2gmlgeometry.o ./ogr/.libs/gml2ogrgeometry.o ./ogr/.libs/<br></blockquote><blockquote type="cite">ogr_expat.o /opt/local/lib/libsqlite3.dylib -L/opt/local/lib -L/usr/<br></blockquote><blockquote type="cite">local/lib /usr/local/lib/libexpat.dylib /usr/local/lib/libjpeg.dylib /<br></blockquote><blockquote type="cite">usr/local/lib/libtiff.dylib /usr/local/lib/libpng12.dylib -lpthread -<br></blockquote><blockquote type="cite">ldl /opt/local/lib/libcurl.dylib /opt/local/lib/libidn.dylib -lssl -<br></blockquote><blockquote type="cite">lcrypto -lz -lOpenCL -install_name /usr/local/lib/libgdal.1.dylib -<br></blockquote><blockquote type="cite">compatibility_version 16 -current_version 16.0 -Wl,-single_module<br></blockquote><blockquote type="cite">ld: library not found for -lOpenCL<br></blockquote><blockquote type="cite">collect2: ld returned 1 exit status<br></blockquote><blockquote type="cite">make[1]: *** [libgdal.la] Error 1<br></blockquote><blockquote type="cite">make: *** [check-lib] Error 2<br></blockquote><blockquote type="cite">seth:gdal-svn-trunk-2010.12.17 sprice$<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">To fix this, I changed "OPENCL_LIB = -lOpenCL" to<br></blockquote><blockquote type="cite">"OPENCL_LIB = -framework OpenCL" in GDALMmake.opt.<br></blockquote><br>I can't help for MacOS build system.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">***** Why is USE_CLAMP_TO_DST_FLOAT in there? I would think that is<br></blockquote><blockquote type="cite">required even if it isn't on ATI. I'm not sure who inserted its use,<br></blockquote><blockquote type="cite">but I'm just wondering if the reasoning is documented somewhere.<br></blockquote><br>It's me. You can find the culprit of any commit by doing a svn blame or looking <br>at the log ;-)<br><br>The reasoning was that I observed with my ATI card that float buffers didn't get <br>to be multiplied by FLT_MAX. The values weren't normalized between 0 and 1, <br>but had directly the expected value. (in the float case, I also dropped the <br>rounding to nearest integer which is clearly not desired, and not in the CPU <br>implementation)<br><br>This is perhaps also needed for NVidia, but I have no way to check, so I just <br>put the condition you saw. If you can check this is unneeded, the condition <br>can go away.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">***** I had to make this change to alg/gdalwarpkernel_opencl.c to get<br></blockquote><blockquote type="cite">it to build without a build option error.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">@@ -1168,7 +1168,7 @@<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"> //Assemble the compiler arg string for speed. All invariants<br></blockquote><blockquote type="cite">should be defined here.<br></blockquote><blockquote type="cite"> sprintf(buffer, "-cl-fast-relaxed-math -Werror -D FALSE=0 -D<br></blockquote><blockquote type="cite">TRUE=1 "<br></blockquote><blockquote type="cite">- "%s "<br></blockquote><blockquote type="cite">+ "%s"<br></blockquote><blockquote type="cite"> "-D iSrcWidth=%d -D iSrcHeight=%d -D iDstWidth=%d -D<br></blockquote><blockquote type="cite">iDstHeight=%d "<br></blockquote><blockquote type="cite"> "-D useUnifiedSrcDensity=%d -D useUnifiedSrcValid=%d "<br></blockquote><blockquote type="cite"> "-D useDstDensity=%d -D useDstValid=%d -D useImag=%d "<br></blockquote><blockquote type="cite">@@ -1176,9 +1176,9 @@<br></blockquote><blockquote type="cite"> "-D nXRadius=%d -D nYRadius=%d -D nFiltInitX=%d -D<br></blockquote><blockquote type="cite">nFiltInitY=%d "<br></blockquote><blockquote type="cite"> "-D PI=%015.15lff -D outType=%s -D dstMinVal=%015.15lff -<br></blockquote><blockquote type="cite">D dstMaxVal=%015.15lff "<br></blockquote><blockquote type="cite"> "-D useDstNoDataReal=%d -D vecf=%s %s -D doCubicSpline=<br></blockquote><blockquote type="cite">%d "<br></blockquote><blockquote type="cite">- "-D useUseBandSrcValid=%d -D iCoordMult=%d",<br></blockquote><blockquote type="cite">+ "-D useUseBandSrcValid=%d -D iCoordMult=%d ",<br></blockquote><blockquote type="cite"> /* FIXME: Is it really a ATI specific thing ? */<br></blockquote><blockquote type="cite">- (warper->imageFormat == CL_FLOAT && warper->bIsATI) ? "-D<br></blockquote><blockquote type="cite">USE_CLAMP_TO_DST_FLOAT=1" : "",<br></blockquote><blockquote type="cite">+ (warper->imageFormat == CL_FLOAT && warper->bIsATI) ? "-D<br></blockquote><blockquote type="cite">USE_CLAMP_TO_DST_FLOAT=1 " : "",<br></blockquote><blockquote type="cite"> warper->srcWidth, warper->srcHeight, warper->dstWidth,<br></blockquote><blockquote type="cite">warper->dstHeight,<br></blockquote><blockquote type="cite"> warper->useUnifiedSrcDensity, warper->useUnifiedSrcValid,<br></blockquote><blockquote type="cite"> warper->useDstDensity, warper->useDstValid, warper-<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">imagWorkCL != NULL,<br></blockquote></blockquote><br>Which error did you get ? You are just changing some whitespace change that <br>seem to be equivalent to the trunk code. Or do I miss something ?<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">**** After doing all of the above to make things compile, I don't get<br></blockquote><blockquote type="cite">the bug described below. I'm working off of the latest trunk daily.<br></blockquote><br>Yeah, that's probably an issue with the ATI SDK.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">~Seth<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On Dec 8, 2010, at 1:12 PM, Even Rouault wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Seth,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Thanks for your help.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">It's more than a little strange that none of those image sizes work.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Perhaps it's a problem with the image format? Can you verify that the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">given format should work?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The image format was CL_UNORM_INT8 (for GDT_Byte)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Looking at the spec, it might also be a problem with the 'sz'<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">argument. What value is that passing?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">It's 1.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I managed to found the following workaround that enables gdalwarp to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">complete<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(see <a href="http://trac.osgeo.org/gdal/changeset/21220">http://trac.osgeo.org/gdal/changeset/21220</a> that basically<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">passes a dummy<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">buffer instead of a NULL pointer).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">However the visual result of the warping is really poor. I see 4<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"ghost"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">images shifted.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">For better understanding I've attached the source image<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(small_world_b1.tif)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and the result of bilinear resampling (but I get similar weird<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">visual effects<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with cubic, cubic spline or lanczos)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">gdalwarp -rb small_world_b1.tif out_bilinear.tif<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Best regards,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Even<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><small_world_b1.tif><out_bilinear.tif><br></blockquote></blockquote></div></blockquote></div><br></body></html>