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