[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