[GRASS-dev] GRASS and GPGPU

[Dylan Beaudette]

On Saturday 01 March 2008, Helena Mitasova wrote:
> Another popular task that has been implemented using GPU is
> insolation, visibility and similar class of tasks,
> so r.sun, r.los would be another candidate modules that could use
> faster implementation.
>
> Helena

I like the sound of r.sun done on the GPU-- that is a very time intensive 
operation, which could use a boost.

Some starters:

# overview presentation:
http://www.cs.unm.edu/~angel/CS534/LECTURES/GPGPU2.pdf

# some discussion
1. http://www.gpgpu.org/forums/index.php?sid=27fd91350f750179126570bde633f792

# open source tools
2. http://sourceforge.net/projects/gpgpu

# an extension to C for stream processing: Brook
3. http://www.gpgpu.org/w/index.php/Brook
4. http://graphics.stanford.edu/projects/brookgpu/lang.html

With some possible drawbacks from [3] :

" However this discounts the important part of transferring the data to be 
processed to and from the GPU. With a PCI Express 1.0 x8 interface, the 
memory of an ATI HD 2900 XT can be written to at about 730Mb/sec and read 
from at about 311Mb/sec which is significantly slower than normal PC memory. 
For large datasets, this can greatly diminish the speed increase of using a 
GPU over a well tuned CPU implementation. Of course, as GPU's become faster 
far more quickly than CPU's and the PCI Express interface improves, it will 
make more sense to offload large processing to GPU's. "

# another library: libSh -- appears to be a well-supported C++ library, and 
metalanguage:
5. http://libsh.org/
6. http://libsh.org/wiki/index.php/Main_Page
7. http://libsh.org/wiki/index.php/Metaprogramming_GPUs_with_Sh
8. http://libsh.org/wiki/index.php/Sample_Code




> On Mar 1, 2008, at 4:38 AM, Benjamin Ducke wrote:
> > Yes, that is an excellent thought. I was considering this
> > possibility for speeding up common interpolation, image
> > transformation and
> > resampling, as well.
> >
> > Kriging in realtime, anyone? ;)
> >
> > Of course, this would have to be implemented in a GPU-specific
> > library.
> >
> > NVidia has the CUDA SDK, which is not open source at the moment, but
> > the pressure is on:
> >
> > http://forums.nvidia.com/lofiversion/index.php?t28458.html
> >
> > ATI already seems to have their stuff (CTM) opened up.
> >
> > Maybe a proof-of-concept GPGPU module would make a nice little SoC
> > project?
> >
> > Benjamin
> >
> > Dylan Beaudette wrote:
> >> Has anyone considered the possibility of doing stream-based
> >> calculations on the GPU [1] for raster operations on large
> >> datasets ? 1. http://en.wikipedia.org/wiki/GPGPU
> >> It appears that this method works best on highly vectorized
> >> instructions, often in 2 "dimensions"-- appropriate for matrix/
> >> grid computations.
> >> Just a thought.
> >> Dylan
> >
> > --
> > Benjamin Ducke, M.A.
> > Archäoinformatik
> > (Archaeoinformation Science)
> > Institut für Ur- und Frühgeschichte
> > (Inst. of Prehistoric and Historic Archaeology)
> > Christian-Albrechts-Universität zu Kiel
> > Johanna-Mestorf-Straße 2-6
> > D 24098 Kiel
> > Germany
> >
> > Tel.: ++49 (0)431 880-3378 / -3379
> > Fax : ++49 (0)431 880-7300
> > www.uni-kiel.de/ufg
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev