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). 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
These also work out well for my thesis work (land cover classification), which gives me extra motivation. 
~Seth
On Friday 02 April 2010, 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). 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
These also work out well for my thesis work (land cover
classification), which gives me extra motivation.
~Seth
Hi,
I think that it sounds like a great idea. Have any ideas on how to keep double
precision when working with the GPU?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
I know that double precision is supported on newer cards and CUDA, but the limitation may be OpenCL. I'm not sure how to best make that work besides making GPU acceleration optional and/or using macros to let the user more easily choose. In the future there will probably be better support in OpenCL, which lends support for macros.
~Seth
via iPhone
On Apr 2, 2010, at 2:03 PM, Dylan Beaudette <debeaudette@ucdavis.edu> wrote:
On Friday 02 April 2010, 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). 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
These also work out well for my thesis work (land cover
classification), which gives me extra motivation.
~Seth
Hi,
I think that it sounds like a great idea. Have any ideas on how to keep double
precision when working with the GPU?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
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@gclements.plus.com>
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@gclements.plus.com>
PS: There is a good discussion of double precision in the first few minutes of this podcast:
http://www.macresearch.org/opencl_episode3
Which also references this PDF:
http://www.nvidia.com/content/nvision2008/tech_presentations/NVIDIA_Research_Summit/NVISION08-Mixed_Precision_Methods_on_GPUs.pdf
~Seth
On Apr 2, 2010, at 2:03 PM, Dylan Beaudette wrote:
On Friday 02 April 2010, 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). 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
These also work out well for my thesis work (land cover
classification), which gives me extra motivation.
~Seth
Hi,
I think that it sounds like a great idea. Have any ideas on how to keep double
precision when working with the GPU?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341