[gdal-dev] Re: OpenCL, GDAL, and You
Even Rouault
even.rouault at mines-paris.org
Tue Dec 7 02:01:41 EST 2010
Le mardi 07 décembre 2010 02:05:51, Seth Price a écrit :
> Ah, the joys of multiple platform development.
>
> The first two warnings should be fixable by replacing "-99.0" with
> "-99.0f".
>
> Your fix for read_imagef() should work fine.
ok, I'll commit that then
>
> To fix that last error, try changing the image size from "1, 1" to "2,
> 2" or "4, 4". It shouldn't matter because the image is there only so
> we have something to pass to the kernel (it's not used in this case).
> The spec says that the values need to be greater or equal to 1, so
> it's technically a SDK problem.
I tried 2,2 ; 4,4 ; 8,8 ; 16,16 ; 256,256; 1024,1024 and none of them work...
> ~Seth
>
> On Dec 6, 2010, at 4:12 PM, Even Rouault wrote:
> > Hi Seth,
> >
> > I gave a try to Frank's integration of your work with my ATI Radeon
> > HD 5400. I
> > got the ATI SDK 2.2 correctly installed with latest ATI drivers
> > (10-11). The
> > few OpenCL demos provided with the SDK I tried work on the GPU device.
> >
> > (Note: "thanks" to the errors bellow, I've made a few cleanups in
> > http://trac.osgeo.org/gdal/changeset/21205 to improve error
> > reporting and
> > clean-up in case of error. I also added missing initialization of 2
> > members of
> > the warper struct)
> >
> > Then I tried a simple warp and I got the following error :
> >
> > """
> > 0ERROR 1: Error: Failed to build program executable!
> > Build Log:
> > Warning: invalid option: -cl-fast-relaxed-math
> >
> > Warning: invalid option: -Werror
> >
> > /tmp/OCL3QLDj2.cl(193): warning: double-precision constant is
> > represented as
> >
> > single-precision constant because double is not enabled
> >
> > return (float2)(-99.0, -99.0);
> >
> > ^
> >
> > /tmp/OCL3QLDj2.cl(193): warning: double-precision constant is
> > represented as
> >
> > single-precision constant because double is not enabled
> >
> > return (float2)(-99.0, -99.0);
> >
> > ^
> >
> > /tmp/OCL3QLDj2.cl(195): error: bad argument type to opencl image op:
> > expected
> >
> > sampler_t
> >
> > CLK_NORMALIZED_COORDS_TRUE |
> > ^
> >
> > 1 error detected in the compilation of "/tmp/OCL3QLDj2.cl".
> >
> > ERROR 1: Error at file gdalwarpkernel_opencl.c line 2228:
> > CL_BUILD_PROGRAM_FAILURE
> > """"
> >
> > Hum, then I looked at similar code in the neighbourhood and I came
> > with the
> > following change that solves the compilation. It is not commited
> > yet, does it
> > look ok to you ?
> >
> > Index: alg/gdalwarpkernel_opencl.c
> > ===================================================================
> > --- alg/gdalwarpkernel_opencl.c (révision 21205)
> > +++ alg/gdalwarpkernel_opencl.c (copie de travail)
> > @@ -724,13 +724,13 @@
> >
> > // Check & return when the thread group overruns the image size
> > "if (nDstX >= iDstWidth || nDstY >= iDstHeight)\n"
> >
> > "return (float2)(-99.0, -99.0);\n"
> >
> > +
> > + "const sampler_t samp = CLK_NORMALIZED_COORDS_TRUE |\n"
> > + "CLK_ADDRESS_CLAMP_TO_EDGE |\n"
> > + "CLK_FILTER_LINEAR;\n"
> > +
> > + "float4 fSrcCoords = read_imagef(srcCoords,samp,fDst);\n"
> >
> > - "float4 fSrcCoords = read_imagef(srcCoords,\n"
> > - "CLK_NORMALIZED_COORDS_TRUE |\n"
> > - "CLK_ADDRESS_CLAMP_TO_EDGE |
> > \n"
> > - "CLK_FILTER_LINEAR,\n"
> > - "fDst);\n"
> > -
> >
> > "return (float2)(fSrcCoords.x, fSrcCoords.y);\n"
> >
> > "}\n";
> >
> >
> > After solving the compilation error, I'm stuck with :
> >
> > """
> > 0ERROR 1: Error at file gdalwarpkernel_opencl.c line 1391:
> > CL_INVALID_IMAGE_SIZE
> > ERROR 1: Error at file gdalwarpkernel_opencl.c line 1391:
> > CL_INVALID_IMAGE_SIZE
> > ERROR 1: Error at file gdalwarpkernel_opencl.c line 2292:
> > CL_INVALID_IMAGE_SIZE
> > ERROR 1: Error at file gdalwarpkernel_opencl.c line 1391:
> > CL_INVALID_IMAGE_SIZE
> > ERROR 1: OpenCL routines reported failure (-40) on line 2570.
> > """
> >
> > The revelant line is :
> > """
> >
> > //Make a fake image so we don't have a NULL pointer
> > (*srcImag) = clCreateImage2D(warper->context, CL_MEM_READ_ONLY,
> >
> > &imgFmt,
> >
> > 1, 1, sz, NULL, &err);
> >
> > handleErr(err);
> >
> > """
> >
> > Any ideas ? Did you try with ATI or NVidia cards ?
> >
> > I've attached the output of CLInfo if it can help.
> >
> > Best regards,
> >
> > Even
> >
> > Le lundi 06 décembre 2010 15:50:04, Seth Price a écrit :
> >> Over the summer I rewrote the warper to use OpenCL. There was a 2x to
> >> 50x speedup. Here is a description of what I did:
> >> http://osgeo-org.1803224.n2.nabble.com/gdal-dev-gdalwarp-OpenCL-Performa
> >> nce -Week-9-td5341226.html
> >>
> >> ~Seth
> >>
> >> On Dec 6, 2010, at 5:10 AM, Konstantin Baumann wrote:
> >>> Hi,
> >>>
> >>> what benefit/improvement would the OpenCL integration bring to GDAL?
> >>> Additional functionality or a speedup of existing functions?
> >>> Probably only operations on images and/or rasters are supported;
> >>> reprojection/warping and filtering would be good candidates, right?
> >>> What concrete operations would be supported?
> >>>
> >>> Kosta
> >>>
> >>> -----Original Message-----
> >>> From: gdal-dev-bounces at lists.osgeo.org
> >>> [mailto:gdal-dev-bounces at lists.osgeo.org ] On Behalf Of Frank
> >>> Warmerdam
> >>> (External)
> >>> Sent: Monday, December 06, 2010 1:43 AM
> >>> To: Seth Price
> >>> Cc: Philippe Vachon; gdal-dev; Wolf Bergenheim
> >>> Subject: [gdal-dev] Re: OpenCL, GRASS, GDAL, and You
> >>>
> >>> On 10-09-23 10:09 AM, Seth Price wrote:
> >>>> Hey all, I was just wondering if there was any progress in
> >>>> integrating
> >>>> the OpenCL code into trunk in each project? I haven't heard
> >>>> anything,
> >>>> but it would be a shame to just leave the code sit, or wait until
> >>>> the
> >>>> code branches have significantly diverged.
> >>>> ~Seth
> >>>
> >>> Seth,
> >>>
> >>> Last week I went out and bought a new AMD/ATI machine in the hopes
> >>> (amoung
> >>> other goals) that OpenCL would work on it with the ATI OpenCL SDK.
> >>> Unfortunately I have discovered that the ATI Radion 4200 HD is not
> >>> supported
> >>> for OpenCL stuff. :-(
> >>>
> >>> Nevertheless, with some persistance I was able to build the ATI SDK,
> >>> and
> >>> configure GDAL to build against it. So I have integrated OpenCL
> >>> support
> >>> in trunk. It is not enabled by default, but you can enable it with
> >>> the
> >>> --with-opencl directive. If the include files and libraries are
> >>> in a
> >>> non-standard location you can also use the --with-opencl-include and
> >>>
> >>> --with-opencl-lib directives to configure like this:
> >>> --with-opencl \
> >>> --with-opencl-include=/home/warmerda/pkg/ati-stream-sdk-v2.2-
> >>>
> >>> lnx64/include \
> >>>
> >>> --with-opencl-lib="-L/home/warmerda/pkg/ati-stream-sdk-v2.2-lnx64/
> >>> lib/x86_64
> >>> -lOpenCL" \
> >>>
> >>> I ran into a few issues:
> >>>
> >>> 1) It seems the include file from ATI is <cl/opencl.h> not <OpenCL/
> >>> OpenCL.h>
> >>> as it is on the Mac. I've put a platform dependent ifdef but I
> >>> don't now
> >>> what the situation will be on other machines.
> >>>
> >>> 2) In your get_device() function you were passing NULL in for the
> >>> platform.
> >>> The online docs indicate this as an option but warn that behavior
> >>> then is
> >>> platform dependent. The ATI SDK just fails with an invalid platform
> >>> error.
> >>> So I updated the code to fetch a platform id and use that.
> >>>
> >>> 3) On my system it falls back to using the CPU but it turns out the
> >>> CPU
> >>> does not offer "image" support in my case. I added some extra logic
> >>> to
> >>> look for this capability so a better error could be reported.
> >>>
> >>> 4) I restructured things a bit so that the OpenCL warper case can
> >>> return
> >>> CE_Warning to indicate to the high level warper that OpenCL should
> >>> be
> >>> skipped and other mechanisms used. That is what it does not if it
> >>> fails
> >>> to find a suitable device, or some of the other specific checks.
> >>>
> >>> 5) I made a few changes to use CPLDebug instead of printf for debug
> >>> output.
> >>>
> >>> I haven't tried this yet on your Mac. I avoided using the account
> >>> you
> >>> kindly offered because I find the Mac is often a perverse build
> >>> environment
> >>> and I didn't want to establish the "norm" based on it. I might try
> >>> it out
> >>> tonight though.
> >>>
> >>> I have also not yet tried it on windows, and likely won't in the
> >>> near future.
> >>> Perhaps someone else will pick up the ball there. The code itself
> >>> just
> >>> depends on having HAVE_OPENCL defined at least in the alg directory
> >>> and
> >>> of course appropriate include and link options.
> >>>
> >>> (cc:ed to the list so everyone is aware of the availability).
> >>>
> >>> Best regards,
> >>>
> >>> _______________________________________________
> >>> gdal-dev mailing list
> >>> gdal-dev at lists.osgeo.org
> >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > <clinfo_ati_radeon_hd_5400.txt>
More information about the gdal-dev
mailing list