Le vendredi 17 décembre 2010 23:41:53, Seth Price a écrit : > 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.
I can't help for MacOS build system. > > ***** 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. It's me. You can find the culprit of any commit by doing a svn blame or looking at the log ;-) The reasoning was that I observed with my ATI card that float buffers didn't get to be multiplied by FLT_MAX. The values weren't normalized between 0 and 1, but had directly the expected value. (in the float case, I also dropped the rounding to nearest integer which is clearly not desired, and not in the CPU implementation) This is perhaps also needed for NVidia, but I have no way to check, so I just put the condition you saw. If you can check this is unneeded, the condition can go away. > > ***** 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, Which error did you get ? You are just changing some whitespace change that seem to be equivalent to the trunk code. Or do I miss something ? > > **** 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. Yeah, that's probably an issue with the ATI SDK. > > ~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