[GRASS-dev] Modules for GPU-based upgrade?

[Seth Price]

If it's a slow module already, there's a good chance it won't be I/O  
bound. Things like bilinear resampling are I/O bound, and wouldn't be  
touched. However, cubic and Lanczos  interpolation are not I/O bound  
and will greatly sped up by way of a GPU.

I think that anything that's noticeably slower than other modules  
shouldn't be I/O bound until we have it running on the GPU. (The GPU  
is often such a compute beast that almost everything becomes  
bottlenecked by the PCI bus, but it's hard to say ahead of time.)
~Seth


On Apr 2, 2010, at 5:45 PM, Glynn Clements wrote:

>
> Seth Price wrote:
>
>> I'm a student interested in a Summer of Code project to improve some
>> modules with GPU-based code. In theory, this could result in a 50x
>> speedup for embarrassingly parallel operations (ie. raster).
>
> Whereas in practice, I/O will be the bottleneck.
>
>> There is
>> a list of some possible modules for upgrade here:
>> http://grass.osgeo.org/wiki/GPU
>>
>> What would the GRASS community think of also including these modules
>> as options for improvement? Do they need a speedup? Am I missing
>> anything?
>>
>> - r.resamp.interp (spline & Lanczos would be added)
>> - r.slop.aspect
>> - r.texture
>> - i.sunhours
>> - i.vi
>
> r.resamp.stats, r.resamp.filter and r.series should also be readily
> parallelisable, but again I/O is likely to be the bottleneck. r.series
> has the advantage that the I/O is also parallelisable.
>
> -- 
> Glynn Clements <glynn at gclements.plus.com>