[Insight-developers] GPU code ready for Gerrit

Xiaoxiao Liu xiaoxiao.liu at kitware.com
Thu Feb 2 14:28:22 EST 2012


Hi Kris,
Thanks for the details.
I think it makes sense to have the GPU modules in different groups
according to their functionality. The only thing I am concerned is that we
lose the convenience of having a Group switch for GPU modules. But I guess
we can use ITK_USE_GPU  to do something similar.

What I did earlier with  5 video modules is that I checked in the least
dependent module(VideoCore) for review first and gradually checked the rest
of modules in bundles according to the module dependencies. I wouldn't
trying to put all modules to review at once. If you check in a giant patch,
it might take longer to review than the patch by patch way. Anyway, just my
two cents.

I could help you to set up a couple of dashboard testing machines. At least
you could submit experimental builds from your machine to make sure
reviewers could verify the patches.

-Xiaoxiao




On Thu, Feb 2, 2012 at 1:46 PM, Kris Zygmunt <krismz at sci.utah.edu> wrote:

> 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><https://github.com/krismz/ITK>
>> 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
>
>


-- 


---------------------------------------------
*Xiaoxiao Liu*, Ph.D.
R & D Engineer
Kitware Inc <http://www.kitware.com/>.
Clifton Park, NY
Phone: (518) 881-4924  or  (518) 371-3971 x124
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20120202/1e0e32b4/attachment.htm>


More information about the Insight-developers mailing list