GPU: Difference between revisions
Jump to navigation
Jump to search
(→Modules of interest to be parallelized: -i.rectify) |
|||
| Line 24: | Line 24: | ||
* <strike>{{cmd|r.mapcalc}}</strike> (already has pthreads support; probably I/O-bound) | * <strike>{{cmd|r.mapcalc}}</strike> (already has pthreads support; probably I/O-bound) | ||
* <strike>{{cmd|r.los}}</strike> (to be replaced by r.viewshed after last few bugs are fixed) | * <strike>{{cmd|r.los}}</strike> (to be replaced by r.viewshed after last few bugs are fixed) | ||
* <strike>{{cmd|i.rectify}}</strike> (to be replaced by GDALwarp API) | * <strike>{{cmd|i.rectify}}</strike> (internal code to be replaced by GDALwarp API) | ||
[[Category: Parallelization]] | [[Category: Parallelization]] | ||
Revision as of 07:54, 1 April 2010
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
Modules of interest to be parallelized
The target version will be GRASS 7 (alias SVN trunk).
- v.surf.rst
- v.vol.rst
- (and/or the RST library in general)
- r.viewshed
- r.sun
- v.net.* ???
- raster library
- vector library
- ...
r.mapcalc(already has pthreads support; probably I/O-bound)r.los(to be replaced by r.viewshed after last few bugs are fixed)i.rectify(internal code to be replaced by GDALwarp API)