[gdal-dev] Re: OpenCL, GDAL, and You
Seth Price
seth at pricepages.org
Tue Dec 7 22:42:31 EST 2010
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?
Looking at the spec, it might also be a problem with the 'sz'
argument. What value is that passing?
~Seth
On Dec 7, 2010, at 12:01 AM, Even Rouault wrote:
> 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