Dylan Beaudette dylan.beaudette at gmail.com
Sun Mar 2 12:55:17 EST 2008

On Sunday 02 March 2008 02:41:07 am Maciej Sieczka wrote:
> Dylan Beaudette pisze:
> > Some starters:
> Also look at Glynn's comments not so long time ago:
> http://www.nabble.com/forum/ViewPost.jtp?post=15573024&framed=y
> Maciek

Thanks for the reminder Maciek.

However, (although I am not a GPU programmer) it looks like the concept of 
stream programming might fit into the GRASS approach of using simple 
formulations over optimized ones-- and here is why:

many raster operations use constructs like the following:

for x in rows:
	for y in cols:
		do_something(x,y, value)

Based on my reading of the GPGPU documents it appears that it is possible to 
give the (libSh/Brook) library the do_something(x, y, value) function (called 
a kernel in stream processing) and the GPU will limplicitly perform the loop 
in parallel. 

If the functionality used in the inner-most loop can be reduced to simple 
operations, it shouldn't be too hard to "drop-in" GPGPU extensions. 

That said, I am not at all experienced with programming the GPU-- however, 
after several years of using R the notion of being able to use vectorized 
functions sounds nice-- especially if the GPU can do those operations 10x 
faster than the CPU.

I think that we would need a simple proof of concept raster module to see how 
hard it would be. I have heard that Manifold GIS has something like this for 
raster operations.


Dylan Beaudette
Soil Resource Laboratory
University of California at Davis

More information about the grass-dev mailing list