<div dir="ltr"><div dir="ltr"><div>Hi,</div><div>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.</div><div>Looking forward to your contributions!<br></div><div>Simon<br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 14, 2019 at 3:38 PM Fredrik Hellman <<a href="mailto:fredrik.hellman@gmail.com">fredrik.hellman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>As far as I understand from <a href="https://devblogs.nvidia.com/gpu-pro-tip-cuda-7-streams-simplify-concurrency/" target="_blank">https://devblogs.nvidia.com/gpu-pro-tip-cuda-7-streams-simplify-concurrency</a>, the default stream is always synchronous if the code is not compiled with the special thread-specific default stream flag.</div><div><br></div><div>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..</div><div><br></div><div>/ Fredrik</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 9 maj 2019 kl 21:46 skrev Simon Rit <<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>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.<br></div><div>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.<br></div><div>Are your developments related to tomographic reconstruction? If yes, is there some RTK algorithms for which you expect a significant improvement?</div><div>Thanks for your suggestions,</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 9, 2019 at 6:08 PM Fredrik Hellman <<a href="mailto:fredrik.hellman@gmail.com" target="_blank">fredrik.hellman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div dir="auto">Hi,</div></div><div dir="auto"><br></div><div dir="auto">Thanks Simon! I see.</div><div dir="auto"><br></div><div>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:</div><div><br></div><div>* 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.</div><div>* 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.</div><div>* Memory allocations. When CUDA memory is allocated and deallocated, it implicitly synchronizes all operations on the GPU (<a href="https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization" target="_blank">https://docs.nvidia.com/cuda/cuda-c-programming-guide/#implicit-synchronization</a>). 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).  </div><div>  <br></div><div>Are these areas that the community would be interested in too? Has there been any developments or discussions about this earlier?</div><div><br></div><div>Best regards,</div><div>Fredrik Hellman</div></div></div><div><div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, 30 Apr 2019 at 15:02, Simon Rit <<a href="mailto:simon.rit@creatis.insa-lyon.fr" target="_blank">simon.rit@creatis.insa-lyon.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div>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.</div><div>Is it something you'd like/need?</div><div>Cheers,</div><div>Simon<br></div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 30, 2019 at 2:58 PM Fredrik Hellman <<a href="mailto:fredrik.hellman@gmail.com" target="_blank">fredrik.hellman@gmail.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I have a question about the the code that deals with cuda within RTK.</div><div><br></div><div>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?</div><div><br></div><div>Best regards,</div><div>Fredrik</div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
Rtk-users mailing list<br>
<a href="mailto:Rtk-users@public.kitware.com" target="_blank">Rtk-users@public.kitware.com</a><br>
<a href="https://public.kitware.com/mailman/listinfo/rtk-users" rel="noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/rtk-users</a><br>
</blockquote></div>
</blockquote></div></div></div>
</div>
</blockquote></div>
</blockquote></div>
</blockquote></div>