Changes between Version 1 and Version 2 of OpenCLIntegration


Ignore:
Timestamp:
May 24, 2010, 10:50:22 AM (14 years ago)
Author:
sprice
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • OpenCLIntegration

    v1 v2  
    1 =OpenCL Integration=
     1= OpenCL Integration =
    22
    3 ==Introduction==
     3== Introduction ==
    44GDAL and GRASS serve as a foundation for many open source projects. For example, GDAL's site lists 67 software packages which use it. Not included, of course, are people such as me who use GDAL and GRASS as stand-alone packages or in nondistributed software. A fundamental improvement in GDAL or GRASS will have a cascading improvement in hundreds of other uses.
    55
    6 ==Background==
     6== Background ==
    77A process as fundamental as imagery resampling is such an improvement. In my experience, a major bottleneck turns out to be this resizing or warping of imagery. In a later section I'll describe in more detail a project where I created a several terabyte imagery dataset. Over half the CPU time was spent resampling pixels.
    88
    … …  
    1111OpenCL is a GPU programming language (similar to C or OpenGL). It is used to write programs which can run on graphics cards (GPUs) and execute hundreds of threads simultaneously. An example of how this works: in image resampling, each pixel must be recalculated as a function of the surrounding pixels, and this must be done for millions (or billions) of pixels. In OpenCL, each thread calculates a pixel simultaneously and speedups in the range of 50 to 100 times can be expected in ideal situations. Advantages of OpenCL are that it should run on more devices and its broad industry support. For more information, see the OpenCL standards website. (http://www.khronos.org/opencl/)
    1212
    13 ==The idea==
     13== The idea ==
    1414I propose to first rewrite GDAL's advanced warping routines to use OpenCL. This alone should result in a massive speedup for many applications. The output of the OpenCL code and original code should be identical, so regression testing should be relatively easy. After testing, I then propose to integrate the new OpenCL code into the GRASS's r.proj. This would result in an increase in both the speed and number of resampling algorithms available to GRASS. Resampling built into the GRASS core (via get row functionality) will also be upgraded as appropriate. Optionally, other GRASS modules that I'm interested in optimizing are r.sun, r.resamp.interp, r.texture, and i.vi. Modules which are I/O bound will not be improved by the use of OpenCL, so I will test the module beforehand to make sure it is CPU bound and parallelizable.
    1515
    16 ==Project plan==
     16== Project plan ==
    1717My work over the summer will follow this plan. Times listed are best guesses, but should be a reasonable target. Note that target timings give one pass through the "optional" steps over the summer.
    18181. Find an appropriate point to integrate OpenCL into GDAL (2 days) and make appropriate changes to the code base (5 days).
    … …  
    2929GOTO 9
    3030
    31 ==Future ideas==
     31== Future ideas ==
    3232In the future, OpenCL will be expandable throughout the codebase as needed. However, Knuth said: "Premature optimization is the root of all evil". Routines should only be rewritten if they have been profiled and found to be both non-I/O-bound and parallelizable. The ideas list (http://grass.osgeo.org/wiki/GRASS_SoC_Ideas) has multiple notes which say "implement multithreading as much as possible". Imagery resampling is only one place for OpenCL's multithreading, I suspect that many opportunities exist in. A list modules is developing on GRASS's GPU page (http://grass.osgeo.org/wiki/GPU).
    3333