[Rtk-users] Stream divisions in rtkfdk

Chao Wu wuchao04 at gmail.com
Wed May 21 08:21:00 EDT 2014


Hi Simon,

Yes I switched on an off the --lowmem option and it has no influence on the
behaviour I mentioned.
In my case the system memory is sufficient to handle the projections plus
the volume.
The major bottleneck is the amount of graphics memory.
If I reconstruct a little bit more slices than the limit that I found with
one stream, the allocation of GPU resource for CUFFT in the
CudaFFTRampImageFilter will fail (which was more or less expected).
However with --divisions > 1 it is indeed able to reconstruct more slices,
but only a very few more; otherwise the CUFFT would fail again.
I would expect the limitations of the amount of slices to be approximately
proportional to the number of streams, or do I miss anything about stream
division?

Thanks,
Chao



2014-05-21 13:43 GMT+02:00 Simon Rit <simon.rit at creatis.insa-lyon.fr>:

> Hi Chao,
> There are two things that use memory, the volume and the projections.
> The --divisions option divides the volume only. The --lowmem option
> works on a subset of projections at a time. Did you try this?
> Simon
>
> On Wed, May 21, 2014 at 12:18 PM, Chao Wu <wuchao04 at gmail.com> wrote:
> > Hoi,
> >
> > I may need some hint about how the stream division works in rtkfdk.
> > I noticed that the StreamingImageFilter from ITK is used but I cannot
> figure
> > out quickly how the division has been performed.
> > I did some test with reconstructing 400 1500x1200 projections into a
> > 640xNx640 volume (the pixel and voxel size are comparable).
> > The reconstructions were executed by rtkfdk with CUDA.
> > When I leave the origin of the volume at the center by default, I can
> > reconstruct up to N=200 slices with --divisions=1 due to the limitation
> of
> > the graphic memory. Then when I increase the number of divisions to 2, I
> can
> > only reconstruct up to 215 slices; and with divisions to 3 only up to 219
> > slices. Does anyone have an idea why it scales like this?
> > Thanks in advance.
> >
> > Best regards,
> > Chao
> >
> > _______________________________________________
> > Rtk-users mailing list
> > Rtk-users at openrtk.org
> > http://public.kitware.com/cgi-bin/mailman/listinfo/rtk-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/rtk-users/attachments/20140521/cd50f7c5/attachment-0009.html>


More information about the Rtk-users mailing list