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
