[Paraview] Rendering performance issue?
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Thu Apr 12 09:53:26 EDT 2012
Frank,
Couple of things to note before share my results:
* When UseOffscreenRenderingForScreenshots is true, ParaView switches to
"offscreen rendering" mode for capturing the view and then switches back to
onscreen mode after the capture. VTK (since before PAraView 3.8) recreates
the window and context everytime one switches from onscreen to offscreen.
Recreating context implies the display lists need to be recreated, among
other things. When UseOffscreenRenderingForScreenshots is 1, I indeed see
the windows being created and destroyed for all versions of ParaView
(3.8.1, 3.10.1, 3.12.0, 3.14.1).
* From ParaView 3.10 on wards, you can additionally set
view.UseOffscreenRendering=1 to avoid the re-creating and destruction of
windows and you'll see similar times
whether UseOffscreenRenderingForScreenshots is ON or OFF. (Except 3.8,
since 3.8 doesn't have UseOffscreenRendering flag).
Using the official binaries on a NVidia Quadro 2000, I see the following
(where offscreen_mode == "UseOffscreenRenderingForScreenshots=1
and UseOffscreenRendering=1 (for PV >3.8.1)" ) and onscreen_mode ==
"UseOffscreenRendering=0, UseOffscreenRenderingForScreenshots=0"
Version offscreen_mode onscreen_mode
3.8.1 110.97* 26.18
3.10.1 10.26 9.65
3.12.0 10.45 9.76
3.14.1 10.67 9.99
Again, note that 3.8.1 offscree_mode timings include the context
creation/deletion time and since there's no easy way to avoid that in
3.8.1, we should take those with a pinch of salt.
Utkarsh
On Wed, Apr 11, 2012 at 10:48 AM, Albina, Frank <
frank.albina at sauber-motorsport.com> wrote:
> Dear Berk!****
>
> ** **
>
> Thank you very much for the reply. ****
>
>
> Actually, I have been able to narrow down the issue I am having by using
> the enclosed script, which uses the paraview.simple.Sphere source to
> perform basic rendering. The output looks like this:****
>
> ** **
>
> [image: spheres--phi=0--theta=0.jpg]****
>
> Until now, all rendering I performed was done with MESA and I have been
> running the rendering scripts by setting
> renderView.UseOffscreenRenderingForScreenshots=1. Now, the interesting bit
> is that running OpenGL with this flag set to 1 does not make a big
> difference for my compiled version of ParaView 3.8.1 but it does for all
> subsequent versions. This is summarized in the table below, which gives the
> time spent in performing rendering and dumping the screenshots to file on
> my test HW:****
>
> ** **
>
> ParaView 3.8.1****
>
> ParaView-3.10.1****
>
> ParaView-3.12.0****
>
> ParaView-3.14.1****
>
> UseOffscreenRenderingForScreenshots=1****
>
> 50.68****
>
> 327.39****
>
> 322.7****
>
> 324.77****
>
> UseOffscreenRenderingForScreenshots=0****
>
> 41.21****
>
> 43.94****
>
> 38.66****
>
> 38.62****
>
> ** **
>
> For all the tests performed, I have been using pvbatch renderSpheres.py. I
> could recover for all PV versions 3.10.1, 3.12.0 and 3.14.1 the same
> rendering time as with UseOffscreenRenderingForScreenshots=1 by running
> pvbatch --use-offscreen-rendering renderSpheres.py, which is allegedly not
> supposed to work unless one uses software rendering. Is there any reason
> why I should not set the flag UseOffscreenRenderingForScreenshots to 1
> when running PV compiled against OpenGL in batch?****
>
> Also, with UseOffscreenRenderingForScreenshots=1, for each screenshot, a
> rendering window opens and closes every time, wherea with
> UseOffscreenRenderingForScreenshots=0, the rendering window stays open the
> whole time and rendering is much faster.****
>
> ** **
>
> Also , out of curiosity, I have recompiled today morning the PV versions
> 3.8.1 & 3.14.1 without MPI support and with the same Qt, Python and gcc
> version (resp 4.6.4, 2.7.2, 4.5.3). Now the results are the following: ***
> *
>
> ** **
>
> ParaView 3.8.1****
>
> ParaView-3.14.1****
>
> UseOffscreenRenderingForScreenshots=1****
>
> 291.11****
>
> 1099.74****
>
> UseOffscreenRenderingForScreenshots=0****
>
> 52.42****
>
> 36.19****
>
> ** **
>
> The PV version 3.14.1 when setting UseOffscreenRenderingForScreenshots to
> 0 fails to generate a correct rendering (see below) while two spheres
> should be visible:****
>
> ** **
>
> [image: spheres--phi=0--theta=0.jpg]****
>
> For me, the only obvious reason for the performance difference here seems
> to be compilation without MPI support, but I will need to check that in
> more details.****
>
> ** **
>
> Concerning the performance hit with MPI in parallel, I found that PV 3.8.1
> was outperforming PV3.10.1 and PV3.12.0 when using offscreen-rendering with
> MESA. I do not have exact numbers, but there was a factor of 50% if I
> recall it correctly. As soon as I have more on this subject, I'll let you
> know.****
>
> ** **
>
> Hope this helps.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Frank.****
>
> ** **
>
> ** **
>
> *From:* Berk Geveci [mailto:berk.geveci at kitware.com]
> *Sent:* Dienstag, 10. April 2012 22:17
> *To:* Albina, Frank
> *Cc:* paraview at paraview.org
> *Subject:* Re: [Paraview] Rendering performance issue?****
>
> ** **
>
> Just out of curiosity, can you compile ParaView without MPI or use the
> ParaView binaries from paraview.org? I am asking this because we have
> been tracking down a nasty rendering performance issue that only shows up
> when ParaView is linked against MPI.****
>
> ** **
>
> -berk ****
>
> On Tue, Apr 10, 2012 at 11:32 AM, Albina, Frank <
> frank.albina at sauber-motorsport.com> wrote:****
>
> Dear ParaView users & developers,****
>
> ****
>
> I am trying to reduce the time spent in performing generic 3D surface
> rendering. A lot has been achieved by using ParaView driven by python
> scripting already but actually I'd like to achieve more. At the time being,
> all rendering is performed using CPU rendering with the MESA libraries and
> I have started investigating if it could be worth performing the rendering
> using GPUs instead of using N CPUs in parallel.****
>
> ****
>
> For the purpose of checking the GPU performance over CPUs, I have devised
> a simple benchmark with a python script which drives the surface rendering.
> The script performs the generation of 60 images and dumps them onto disk in
> JPEG format. When performing this task, I have been tumbling upon the
> following rendering times for the generation of the aforementioned 60
> images, using different versions of paraview on an "old" workstation, which
> is my guinea pig for this benchmark:****
>
> ****
>
> Paraview 3.8.1****
>
> Paraview 3.10.1****
>
> Paraview 3.12.0****
>
> Paraview 3.14.1****
>
> 138.12s****
>
> 591.06s****
>
> 592.53s****
>
> 594.10s****
>
> ****
>
> What is striking is that the rendering time *is 4 times less(!)* with PV
> v3.8.1 than with all subsequent versions. I had already noticed something
> similar when running MESA on dissimilar architectures, but I assumed that
> the culprit were the MESA libraries used. Here, the HW and libraries are
> the same, so I am enclined to believe that I am missing something here in
> the general rendering settings which do not affect PV v3.8.1 but induce a
> big performance hit for all PV versions above 3.10. Is anybody aware of
> rendering settings which could induce such a performance difference?****
>
> ****
>
> BTW, for each rendering, a window opens with the OpenGL tag in the window
> title bar, so I am quite sure that I am not using any SW rendering, all the
> more as all the PV versions I have compiled have VTK_OPENGL_HAS_OSMESA set
> to off.****
>
> ****
>
> A few more details concerning the test I have been running:****
>
> ****
>
> - Workstation: Linux workstation with SuSE SLED 10****
>
> 2 x Intel Xeon Dual core 5160 @ 3.00GHz ****
>
> 2 x NVIDIA Quadro FX3500 (NV71GL chipset)****
>
> ****
>
> - Paraview version 3.8.1, 3.10.1, 3.12.0 and 3.14.1 were compiled with
> OpenGL support, Qt v4.6.x, python v2.7, OpenMPI v1.4.x using the GCC
> compiler v4.5.x.****
>
> ****
>
> - The script is run using pvpython (and not pvbatch) in order to force
> the assignement of the graphics card:****
>
> pvserver -display localhost:0.0 ****
>
> Then the rendering script runs with pvpython from the command line.
> Within the script, a Connect("localhost",11111) forces the connection to
> the pvserver running on localhost.****
>
> ****
>
> Any suggestions welcome.****
>
> Best regards ****
>
> Frank Albina.****
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview****
>
> ** **
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120412/0a2dd6fe/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 7146 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120412/0a2dd6fe/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 13332 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120412/0a2dd6fe/attachment-0003.jpeg>
More information about the ParaView
mailing list