Changes between Version 2 and Version 3 of OpenCLIntegration


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

--

Legend:

Unmodified
Added
Removed
Modified

  • OpenCLIntegration

    v2 v3  
    1616== 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.
    18 1. Find an appropriate point to integrate OpenCL into GDAL (2 days) and make appropriate changes to the code base (5 days).
    19 2. Get OpenCL code functioning in GDAL which duplicates existing GDAL functionality (but much faster; 20 days).
    20 3. Test code in GDAL and fix any bugs (5 days). New and old output images should be identical.
    21 4. Find an appropriate point to integrate the OpenCL code into the GRASS r.proj module. This will be complicated because as much of the raster as possible will need to be loaded into the GPU memory while being processed, which conflicts with current get-row functionality (2 days).
    22 5. Copy the OpenCL warping code from GDAL to GRASS (5 days), bringing new resampling algorithms to GRASS. I expect the OpenCL code to be identical between GDAL and GRASS, making maintenance easier. The major differences will be the support code within GRASS.
    23 6. Test code in GRASS, fix bugs, and discover any necessary customizations (4 days).
    24 7. Test core GRASS resampling code, which is normally used via the get-row functionality. If necessary (it isn't I/O bound), I'll adapt the projection code to work with resampling here (5 days). Ideally, the same code can be used because the get-row resampling functionality is a sub-set of projection warping functionality.
    25 8. Test OpenCL code against regular CPU output (3 days).
    26 9. (optional) I'm unsure how much time the previous steps will take. At this point I should have plenty of OpenCL experience, though. I hope to also test other GRASS modules for potential speedup (2 days). I am particularly interested in r.sun, r.resamp.interp, r.resamp.stats, r.texture, r.slope.aspect, i.sunhours, and i.vi, but many of these may be found to be I/O bound. GDAL code will also be considered as appropriate (suggestions?).
    27 10. (optional) Rewrite other module as the necessity and opportunity presents itself (15 days).
    28 11. (optional) Test new module code (5 days).
    29 GOTO 9
     18 1. Find an appropriate point to integrate OpenCL into GDAL (2 days) and make appropriate changes to the code base (5 days).
     19 2. Get OpenCL code functioning in GDAL which duplicates existing GDAL functionality (but much faster; 20 days).
     20 3. Test code in GDAL and fix any bugs (5 days). New and old output images should be identical.
     21 4. Find an appropriate point to integrate the OpenCL code into the GRASS r.proj module. This will be complicated because as much of the raster as possible will need to be loaded into the GPU memory while being processed, which conflicts with current get-row functionality (2 days).
     22 5. Copy the OpenCL warping code from GDAL to GRASS (5 days), bringing new resampling algorithms to GRASS. I expect the OpenCL code to be identical between GDAL and GRASS, making maintenance easier. The major differences will be the support code within GRASS.
     23 6. Test code in GRASS, fix bugs, and discover any necessary customizations (4 days).
     24 7. Test core GRASS resampling code, which is normally used via the get-row functionality. If necessary (it isn't I/O bound), I'll adapt the projection code to work with resampling here (5 days). Ideally, the same code can be used because the get-row resampling functionality is a sub-set of projection warping functionality.
     25 8. Test OpenCL code against regular CPU output (3 days).
     26 9. (optional) I'm unsure how much time the previous steps will take. At this point I should have plenty of OpenCL experience, though. I hope to also test other GRASS modules for potential speedup (2 days). I am particularly interested in r.sun, r.resamp.interp, r.resamp.stats, r.texture, r.slope.aspect, i.sunhours, and i.vi, but many of these may be found to be I/O bound. GDAL code will also be considered as appropriate (suggestions?).
     27 10. (optional) Rewrite other module as the necessity and opportunity presents itself (15 days).
     28 11. (optional) Test new module code (5 days).
     29 12. GOTO 9
    3030
    3131== Future ideas ==