[Insight-developers] GPU code ready for Gerrit

Kris Zygmunt krismz at sci.utah.edu
Thu Feb 2 13:46:38 EST 2012


Hi Xiaoxiao,
    Basically what I have done is taken Won-Ki's code, made sure it passes tests on multiple platforms, cleaned up warnings, and then done some cmake fixes to convert the gpu kernels to strings.
> >> Extra comments:
> I saw the GPU modules are in Core group. How about  making a GPU group? So that later gpu modules could naturally located in the same group folder?

  I have also changed the gpu directory structure.  Originally, everything was in Modules/GPU/Common, I have changed it to the following where there is a corresponding GPU folder for each module that has both a CPU and GPU implementation:

Modules
      Core
          Common
          GPUCommon
           ...
      Filtering
           Smoothing
           GPUSmoothing
            Thresholding
            GPUThresholding
             ...
       ...
> I have performed a series of commits while working from my github https://github.com/krismz/ITK  GPU-Beta-R1 branch, is it worth saving these as a series of commits when pushing to gerrit or is it better to squash them into a single commit and lose some of the details of the changes made?  If I push a series of commits to gerrit, what is the correct way to do that to keep from creating multiple gerrit topics?
> >> It is the best to make small changes from the very beginning to avoid the giant-commit problem. But I guess it is too late now.  If you don't mind losing your development history in ITK history, you could do the single commit; If not, there are some git magic (norecommended, but Brad King knows how ) that  may help you to merge in the commit history. But either way, you might want to send the giant patch to gerrit for review first .  Looks like your github version of ITK is synced with the main ITK repo, which is good.  How about sending patches to gerrit by modules ? One GPU module as one topic  commit?
> 

I think it could be hard to provide a gerrit patch for each module separately and maintain the commit history of the changes I made.  The main reason I worked out of github was to get the GPU code mature enough for inclusion without disrupting the ITK 4 RC schedule.  So I suppose it comes down to asking what is preferred, making 7 different gerrit patches where each patch is one GPU module (each module has between 1 and 29 files in it) and losing any intermediate commit history or providing one large patch with all of the GPU code together?  I am concerned that providing a series of smaller patches will complicate things as each module except for Core/GPUCommon is dependent on other GPU modules, so ther would be complicated structure of linked gerrit patches to manage through the review process.  I think it would also be harder to manage STYLE changes across multiple gerrit patches.  Anyway, just my 2 cents, I will do whatever is preferred to help these changes get reviewed and merged quickly.

> Also, You probably want to set up at least one dashboard machine with GPU for the nightly dashboard.
Can this machine be set up to use the gerrit code, or should it wait until after the code is merged in?  The nightly dashboard machine will need to have OpenCL installed and a relatively modern GPU card.  Then the only extra thing is to configure cmake with ITK_USE_GPU turned ON.  Can someone help configure one of the existing dashboard machines for this?

-Kris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20120202/ee0630aa/attachment.htm>


More information about the Insight-developers mailing list