[Paraview] Rendering performance issue?

Fri Apr 13 13:12:32 EDT 2012

Hi Utkarsh!

Thank you very much for your help. You made my day. Indeed, all PV versions from PV3.10 are much faster when the flag view.UseOffscreenRendering=1 is set.  Now, I am down to roughly 85s instead of the 595s reported in my first email for all versions 3.10.1, 3.12.0 and 3.14.1.

I will rerun our benchmark with MESA on my guinea pig computer and I will share the results on this forum. This is of interest for me since I need to check the parallel efficiency between all versions as well, which will help me decide if I remain with MESA rendering or not.

Cheers,

Frank.

From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com]
Sent: Donnerstag, 12. April 2012 15:53
To: Albina, Frank
Cc: Berk Geveci; paraview at paraview.org
Subject: Re: [Paraview] Rendering performance issue?

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<mailto: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:

[cid:image001.jpg at 01CD19A8.03F9B8F0]
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:

[cid:image002.jpg at 01CD19A8.03F9B8F0]
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<mailto:berk.geveci at kitware.com>]
Sent: Dienstag, 10. April 2012 22:17
To: Albina, Frank
Cc: paraview at paraview.org<mailto: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<http://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<mailto: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<http://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<http://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/20120413/245abbc0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7146 bytes
Desc: image001.jpg
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120413/245abbc0/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 13332 bytes
Desc: image002.jpg
URL: <http://www.paraview.org/pipermail/paraview/attachments/20120413/245abbc0/attachment-0003.jpg>