[GRASS-dev] Parallel computing for r.sun

[Seth Price]

On the Mac, you're compiling with "-framework OpenCL"

~Seth


via iPhone

On Jan 29, 2013, at 9:14 PM, Yann Chemin <yann.chemin at gmail.com> wrote:

> Hi Hamish,
> 
> """
> the first step is to get support for OpenCL build into grass7's
> ./configure next to pthreads and OpenMP which are already there.
> I welcome help with that, my copious free time hasn't been
> very good lately.
> """
> 
> I am heading to the code sprint in Genoa on Sunday,
> Could you spend a little time explaining me the directions to do that?
> (URL, PDF, anything welcome)
> 
> 
> Cheers,
> Yann
> 
> 
> On 30 January 2013 08:19, Hamish <hamish_b at yahoo.com> wrote:
>> Yann wrote:
>> > anyone has a timeline for merging the OpenCL code into trunk?
>> 
>> Hi,
>> 
>> that's been on my todo list for way too long.
>> 
>> the first step is to get support for OpenCL build into grass7's
>> ./configure next to pthreads and OpenMP which are already there.
>> I welcome help with that, my copious free time hasn't been
>> very good lately.
>> 
>> The removal of tertiary calls from the main r.sun loop has
>> already been done in trunk.
>> 
>> I'll try to write more after work, but a lot is explained
>> on these pages:
>>   http://grasswiki.osgeo.org/wiki/Category:Parallelization
>> 
>> besides the r.sun work already done, AFAIAC the top candidates
>> for parallelization in GRASS are v.surf.rst and v.surf.bspline.
>> Currently there is some support directly in the LU decomposition
>> but that makes 1000s of threads; the cost of creating and
>> destroying those is coming down a lot, but I think it will
>> probably be a lot more efficient to only create dozens of
>> threads in the case of v.surf.bspline (see code comment at
>> the start of the loop where the OpenMP support could go)
>> and for v.surf.rst perhaps multithread the various boxes of
>> the quadtree?  The idea being to more closely match the
>> number of threads/processes with the number of CPUs or GPUs.
>> For CPUs that means dozens, for GPUs that means hundreds.
>> 
>> Each module will be different, so each one requires its own
>> approach. For that reason I'm happy for pthreads, OpenMP,
>> and OpenCL to all be supported.
>> 
>> various python and bourne shell scripts (quite new so not
>> backported to 6.4.svn yet) have been parallelized; the easy
>> win is to run the three R,G,B bands in parallel. It only
>> scales to 3 CPUs, but is nearly perfectly efficient and a 3x
>> speedup is as good as any. See the v.surf.icw script in both
>> g6.sh and g7.py addons for a complete example.
>> 
>> the good news is that slowly the opencl apis are making their
>> way into the mainstream driver releases, even intel is on board.
>> before you pretty much needed to tailor your linux distro to
>> match their SDK release target if you wanted to use it; and
>> then the SDK didn't match with the available driver version,
>> and other such pain..
>> 
>> I'm not sure of what modules in GRASS besides r.sun are well
>> suited to GPU acceleration. r.sun as a ray-tracing exercise
>> was an obvious one as that's what GPUs are generally designed
>> to do these days. Much, if not most, of GRASS's modules are
>> I/O limited, and especially I/O to the video card has
>> traditionally been really slow. (that's getting better to, but
>> still a little on the horizon).
>> 
>> another thing to consider is that GPU math on consumer-grade
>> video cards have been traditionally limited to float()s. you
>> had to buy the expensive "science grade" one if you wanted to
>> calc using double prec. FPs.
>> 
>> great leaps can be made, but there are some caveats to consider.
>> 
>> 
>> best,
>> Hamish
> 
> 
> 
> -- 
> Yann Chemin
> Researcher at IWMI
> Skype/FB: yann.chemin
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20130129/4318df01/attachment.html>