GPU: Difference between revisions
Jump to navigation
Jump to search
(howto) |
|||
Line 45: | Line 45: | ||
* {{cmd|r.viewshed|version=70}} | * {{cmd|r.viewshed|version=70}} | ||
* {{cmd|v.surf.bspline|version=70}} | * {{cmd|v.surf.bspline|version=70}} | ||
* {{cmd|r.sun|version=70}} | * {{cmd|r.sun|version=70}} (Seth added support has part of his Google Summer of Code project) | ||
* {{cmd|r.proj|version=70}} | * {{cmd|r.proj|version=70}} | ||
* {{cmd|v.proj|version=70}} | * {{cmd|v.proj|version=70}} |
Revision as of 08:01, 30 April 2013
Implementation
In GRASS 7 you can ./configure GRASS with:
--with-opencl
On Linux you'll need to use the proprietary driver from nVidia, AMD (ATI), or Intel. Point --with-opencl-includes= to the directory above cl.h, and as long as libOpenCL.so is in the ldconfig search path you're ok (a symlink to /usr/local/lib might be needed). On Mac OSX OpenCL support is now built in, and the framework should be automatically detected when you use --with-opencl in the ./configure options.
Currently r.sun is the first module with any OpenCL support, although integration of Seth's work into svn-trunk is not yet complete.
Discussion
Comments from the mailing list concerning GRASS and GPU parallelization:
- Discussion - GPU Parallelization (follow thread)
- Discussion - OpenCL Parallelization (follow thread)
- Comment
- Comment
- As I understand it, CUDA is 100% dependent on the closed-source binary driver from nVidia and works on their video cards alone. Which is fine for today for people with nVidia hardware using their binary video card driver. If nVidia decides in a couple of years to stop supporting CUDA, your old card, your specific OS or distro, your OS or distro version+cpu type, or if they go out of business or are bought/sold to another company who is not interested, any code based on it becomes useless. For this reason code written for an open platform such as OpenCL, even if less advanced, seems to have a brighter long-term future. -- HB
- Support for double precision floating point values must be retained for calculations which deal with positional data (as sub-meter precision for lat/long exceeds single-precision floating poing). For elevation and radiometric data floating point precision may be enough.
Further reading
- Steinbach, M., Hemmerling, R., 2011. Accelerating batch processing of spatial raster analysis using GPU. Computers & Geosciences. DOI
- LINUX Magazine March 10th, 2010: "GP-GPUs: OpenCL Is Ready For The Heavy Lifting", http://www.linux-mag.com/id/7725
- See the "Parallelization" category listing at the bottom of this page.
- OpenCL podcasts: http://www.macresearch.org/opencl
Modules of interest to be parallelized
The target version will be GRASS 7 (alias SVN trunk).
- v.in.ogr or → underlying vector library functions to build topology and spatial index ←
- v.surf.rst
- v.vol.rst
- (probably best to focus on the RST library first)
- r.viewshed
- v.surf.bspline
- r.sun (Seth added support has part of his Google Summer of Code project)
- r.proj
- v.proj
- v.net.* ???
- raster library (typically I/O-bound)
- i.rectify
- ...
r.mapcalc(already has pthreads support (but only for parsing!!); probably I/O-bound)