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:
get_cell_value(x,y,)
do_something(x,y, value)
end
end
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
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
