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 <[email protected]>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
