[GRASS-dev] Parallel computing for r.sun

[Yann Chemin]

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/20130130/4c1e4b12/attachment.html>