Volume rendering fluidity on big volume

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Volume rendering fluidity on big volume

chir.set@free.fr
Hello,

I wish to expose a situation about the motion fluidity of a Volume Rendering
model, derived from a big DICOM dataset.

I changed my graphics card for a more recent and powerful one, featuring an
AMD RX480 GPU with 8 GB RAM. I'm using it on Linux with the amdgpu-pro 16.50
driver. My previous card was a Radeon HD 6870 with 2 GB RAM using fglrx. The
PC has an AMD Phenom II X6 1100T CPU at 3.3 GHz and 16 GB RAM.

The main problem : I have been quite deceived to see that there persists a lag
between start and end of a movement applied to a big Volume Rendering model,
about 2 seconds, where I don't see a continuous view update. There are also
glitches between start and end with the new card, which I attribute to the
driver in use. These can disappear by reducing the fps rate. But the lag
remains the same.

If I crop the volume to a smaller one, moving around the resulting model is as
fluid as I would expect.

I can understand there's more computation to do the bigger the model. But I am
puzzled that a more powerful graphical computation unit does not yield a
better result in the above explained situation.

This leads me to one question : is there room for optimization of Slicer's
code in this context ?

This link (http://vasc.free.fr/sample.zip) provides an anonymized dataset for
illustration, and a screencast of such a model being moved around (I'll delete
the file in a few days. 488 MB).

Thank you for providing your views on this question.

Regards.

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Volume rendering fluidity on big volume

Andras Lasso-2
How much GPU memory have you allocated for volume rendering? (Volume rendering module / Advanced section / Techniques / GPU memory size)

The root cause of the problem is most that rendering in GPU volume mappers in VTK cannot be aborted (renderWindow()->GetAbortRender() flag is ignored). Therefore, if you already start a long rendering operation you don't have any other choice than waiting for completion before you start a new rendering. You may try to ask on the VTK mailing list if it is difficult to add AbortRender check or if it just there because GPU-based rendering is generally fast enough so nobody asked for it.

Andras

-----Original Message-----
From: slicer-users [mailto:[hidden email]] On Behalf Of SET
Sent: January 9, 2017 10:45
To: SPL Slicer Users <[hidden email]>
Subject: [slicer-users] Volume rendering fluidity on big volume

Hello,

I wish to expose a situation about the motion fluidity of a Volume Rendering model, derived from a big DICOM dataset.

I changed my graphics card for a more recent and powerful one, featuring an AMD RX480 GPU with 8 GB RAM. I'm using it on Linux with the amdgpu-pro 16.50 driver. My previous card was a Radeon HD 6870 with 2 GB RAM using fglrx. The PC has an AMD Phenom II X6 1100T CPU at 3.3 GHz and 16 GB RAM.

The main problem : I have been quite deceived to see that there persists a lag between start and end of a movement applied to a big Volume Rendering model, about 2 seconds, where I don't see a continuous view update. There are also glitches between start and end with the new card, which I attribute to the driver in use. These can disappear by reducing the fps rate. But the lag remains the same.

If I crop the volume to a smaller one, moving around the resulting model is as fluid as I would expect.

I can understand there's more computation to do the bigger the model. But I am puzzled that a more powerful graphical computation unit does not yield a better result in the above explained situation.

This leads me to one question : is there room for optimization of Slicer's code in this context ?

This link (http://vasc.free.fr/sample.zip) provides an anonymized dataset for illustration, and a screencast of such a model being moved around (I'll delete the file in a few days. 488 MB).

Thank you for providing your views on this question.

Regards.

_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ
Reply | Threaded
Open this post in threaded view
|

Re: Volume rendering fluidity on big volume

chir.set@free.fr
In reply to this post by chir.set@free.fr
Le lundi 16 janvier 2017 15:06:57 CET Andras Lasso a écrit :

> How much GPU memory have you allocated for volume rendering? (Volume
> rendering module / Advanced section / Techniques / GPU memory size)
>
> The root cause of the problem is most that rendering in GPU volume mappers
> in VTK cannot be aborted (renderWindow()->GetAbortRender() flag is
> ignored). Therefore, if you already start a long rendering operation you
> don't have any other choice than waiting for completion before you start a
> new rendering. You may try to ask on the VTK mailing list if it is
> difficult to add AbortRender check or if it just there because GPU-based
> rendering is generally fast enough so nobody asked for it.
>
> Andras



I allocated 8GB for Volume Rendering in settings. I'll try a request with the
VTK folks ASAP.

Thanks for your reply.





_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
http://www.slicer.org/slicerWiki/index.php/Documentation/4.3/FAQ