[GRASS-dev] GRASS and GPGPU

Dylan Beaudette dylan.beaudette at gmail.com
Sun Mar 2 18:49:49 EST 2008


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

One more post on this today, and then I am done looking into GPGPU computation 
for a while.

Some initial tests with the libSh code resulted in odd results: the CPU 
version was an order of magnitude faster than the GPU version. It could be 
that I didn't have something set up correctly...

It also looks like libSh is not being actively maintained, with more of their 
efforts going toward a commercial product. 

Finally, this page [1] has enough details to keep anyone interested reading 
for a while. However, it suggests that GPGPU operations are limited (for the 
most part) to semi-32bit floating point numbers. Might be a show-stopper for 
working with anything by FCELL maps...

1. http://www.gpgpu.org/w/index.php/FAQ

Dylan


> 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



-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341


More information about the grass-dev mailing list