Hi, Ok, I think the concept of streams is something different from what I had in mind. We don't use them (i.e., we use the default). What I meant is that I believe that memory transfers (cumemcpy) are asynchronous and overlap with the computation in the current implementation. I'm not sure this is optimally implemented but I believe there is some. Looking forward to your contributions! Simon
On Tue, May 14, 2019 at 3:38 PM Fredrik Hellman <[email protected]> wrote: > Hi, > > Ok, thank you! Although I have no concrete changes in mind already now, I > at least know that the itk cuda common code is maintained via RTK and open > for contributions. > > As far as I understand from > https://devblogs.nvidia.com/gpu-pro-tip-cuda-7-streams-simplify-concurrency, > the default stream is always synchronous if the code is not compiled with > the special thread-specific default stream flag. > > Yes, it is for tomographic reconstruction, so I use some RTK code, e.g. > FDK reconstruction. But I am writing some of my own filters that should > work together with it, using the itk Cuda Image as image type. So no, I > don't have any special algorithm from RTK in mind.. > > / Fredrik > > Den tors 9 maj 2019 kl 21:46 skrev Simon Rit < > [email protected]>: > >> Hi, >> I would definitely be interested in improving RTK! We haven't discussed >> about this earlier and I don't see why the community would not be >> interested in improvements. If you start coding something, my preferences >> would be to have backward compatible code. Feel free to propose some PRs. >> I'm a bit surprised about your comment on streams, I was pretty sure that >> the computation and the data transfer were asynchronous as is. And about >> the memory pool, why not, that sounds interesting, as long as we can still >> allocate as much as before. About the streaming part, if does not >> reallocate if there is no change in memory size I believe. >> Are your developments related to tomographic reconstruction? If yes, is >> there some RTK algorithms for which you expect a significant improvement? >> Thanks for your suggestions, >> Simon >> >> On Thu, May 9, 2019 at 6:08 PM Fredrik Hellman <[email protected]> >> wrote: >> >>> Hi, >>> >>> Thanks Simon! I see. >>> >>> I am writing a CUDA application of which where RTK and ITK will be >>> parts, and I want to know how RTK CUDA cooperates with the CUDA >>> functionality I already have in my application. I have found some behaviors >>> that would be nice to be able to control/change or at least understand the >>> design of: >>> >>> * Context handling. It appears the CUDA context manager keeps track of >>> contexts and also can switch between them, I think I would like to be able >>> to control this on a higher level. I can see situations where multple >>> libraries compete with the control of contexts. >>> * Streams. It would be nice to be able to perform data transfer between >>> CPU/GPU in parallell with computations, but that requires that another >>> stream than the default stream is used, since the default stream is always >>> synchronous. >>> * Memory allocations. When CUDA memory is allocated and deallocated, it >>> implicitly synchronizes all operations on the GPU ( >>> https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization). >>> It would be good if one could either provide allocators/deallocates for a >>> memory pool which doesn't need to issue the actual allocation calls, but >>> get buffers from a pre allocated pool. Or find a a way to disable >>> reallocations (which sometimes can be very frequent in ITK, especially if >>> doing streaming). >>> >>> Are these areas that the community would be interested in too? Has there >>> been any developments or discussions about this earlier? >>> >>> Best regards, >>> Fredrik Hellman >>> >>> On Tue, 30 Apr 2019 at 15:02, Simon Rit <[email protected]> >>> wrote: >>> >>>> Hi, >>>> Everything you're saying is correct. This development was co-funded by >>>> the RTK consortium and Kitware and the goal was to transfer it to ITK. >>>> However, this has never occurred and at this stage, it is only maintained >>>> in RTK. Ideally, this could become an independent ITK module. >>>> Is it something you'd like/need? >>>> Cheers, >>>> Simon >>>> >>>> On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman < >>>> [email protected]> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I have a question about the the code that deals with cuda within RTK. >>>>> >>>>> RTK uses itk cuda image, the itk data manager, and itk context manager >>>>> (but not itk kernel manager so much?) to handle cuda data. Is this >>>>> maintained as part of RTK or is it maintained somewhere else and only used >>>>> in RTK? Now when RTK becomes closer to ITK, what will happen to that code? >>>>> >>>>> Best regards, >>>>> Fredrik >>>>> >>>> _______________________________________________ >>>>> Rtk-users mailing list >>>>> [email protected] >>>>> https://public.kitware.com/mailman/listinfo/rtk-users >>>>> >>>>
_______________________________________________ Rtk-users mailing list [email protected] https://public.kitware.com/mailman/listinfo/rtk-users
