Dear Kevin!

To put things more clearly and to avoid confusion, I'd like to build a paraview 
v3.10.x executable with X. In this regard, I'd like to use paraview as the 
client and start remotely the paraview server with mpirun -np <N> 
--use-offscreen-rendering. Following the description on the Paraview WIKI,

http://paraview.org/Wiki/ParaView/Users_Guide/Parallel_Rendering#Offscreen_software_rendering_via_OSMesa

I *should* be able to build paraview with X using offscreen rendering, based on 
the MESA libraries. Again, this worked with paraview v3.8.1, but I fail getting 
it up and running with paraview 3.10.x performing the same configuration steps 
as with paraview 3.8.1.

If I understood you well, one cannot link an application to libOSMESA.so and 
libGL.so/libGLU.so at the same time. If this is correct, then it would explain 
why I get a segmentation fault straight away. On the other hand, what are then 
the libGL.so and libGLU.so one has to link against, if not the ones from MESA 
v7.x according to the WIKI:

[...]
You can use it as a supplement to onscreen rendering. This mode requires that 
you have a display (X11 is running). In addition to specifying the GL library 
(which may be a GPU implementation of the Mesa one above), you must tell 
ParaView where Mesa's OSMesa library is. Do that by turning the 
VTK_OPENGL_HAS_OSMESA variable to ON. After you configure again you will see a 
new CMake variable called OSMESA_LIBRARY. Set this to the libOSMesa library 
file.

PARAVIEW_BUILD_QT_GUI   ON
VTK_USE_COCOA           ON                              Mac Only. X11 is not 
supported.
VTK_OPENGL_HAS_OSMESA   ON                              Turn this to ON to 
enable software rendering.
OSMESA_INCLUDE_DIR      <mesa include dir>      Set this to the include 
directory for MESA.
OPENGL_INCLUDE_DIR      <mesa include dir>      Set this to the include 
directory for MESA.
OPENGL_gl_LIBRARY       libGL                   Set this to the libGL.a or 
libGL.so file.
OPENGL_glu_LIBRARY      libGLU                  Set this to the libGLU.a or 
libGLU.so file.
OSMESA_LIBRARY          libOSMesa                       Set this to the 
libOSMesa.a or libOSMesa.so file.

If one tries to use the libGL.so/libGLU.so libraries, here is the output of 
CMake, wether you use the mesa include dir or the system include dir for 
OPENGL_INCLUDE_DIR.

[...]
CMake Warning at VTK/CMake/vtkTargetExportMacros.cmake:6 (ADD_LIBRARY):
   Cannot generate a safe runtime search path for target vtkftgl because files
   in some directories may conflict with libraries in implicit directories:

     runtime library [libGL.so.1] in /usr/lib64 may be hidden by files in:
       /code/CFD/develop/opt/share/Mesa-7.9.2/lib

   Some of these libraries may not be found correctly.
 Call Stack (most recent call first):
   VTK/Utilities/ftgl/CMakeLists.txt:151 (VTK_ADD_LIBRARY)
[...]

. Please correct me if I am wrong, but everything points me towards using the 
libGL.so and libGLU.so from the MESA libs installation.

Finally, there is now an additional setup variable OPENGL_xmesa_INCLUDE_DIR. 
Where should this variable point to? With GPU support, this points to the 
system include files.

Thank you very for your help anyway and please let me know if you have made any 
progress with building paraview on your cluster.

Cheers,

Frank.

-----Original Message-----
From: Kevin H. Hobbs [mailto:hob...@ohio.edu]
Sent: Dienstag, 19. April 2011 13:23
To: Albina, Frank
Cc: David Partyka; paraview@paraview.org
Subject: Re: [Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA 
support on.

On 04/19/2011 01:59 AM, Albina, Frank wrote:
> Hi Kevin!
>
> Thanks a lot for the offer. To be honest, I am still having trouble to run 
> paraview v3.10.0/v3.10.1 to have CPU rendering only with additional X support.

This statement confuses me.

There are two* ways to build paraview :

1. With X : Hardware accelerated or not, onscreen or not, X is required.

2. Without X : No hardware acceleration, always offscreen, X is not required at 
all.


*OK, OK there are other window systems for Mac and Windows

> On the one hand, I am performing the same configuration steps with CMake as 
> for paraview 3.8.1, for which I have had no issues whatsoever wrt. running 
> paraview in this configuration for the last 4 months. I am relying heavily on 
> paraview for post-processing simulation results and it runs on my compute 
> cluster daily in parallel.
>
> On the other hand, performing the same configuration steps with CMake for 
> paraview 3.10.0 or 3.10.1 creates an executable which cannot run without 
> producing a segmentation fault, which does appear just after the logo window 
> has popped up. For information, I am compiling the paraview sources from 
> scratch.

After I'm sure you have Mesa and PV builds that will work we'll check that you 
are linking against the right libraries.

I can't tell you how many times I've thought I've set up Mesa correctly only to 
discover that PV was linking against the system GL.

> Here are the settings I am using by default:
>
> OPENGL_gl_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/
> libGL.so

The above is an Open GL library.

> OSMESA_LIBRARY:FILEPATH=/code/CFD/develop/opt/share/Mesa-7.9.2/lib/lib
> OSMesa.so
>

The above is also an Open GL library you can not link an application to both of 
them at the same time.


>> make realclean
>> ./configure --prefix=/code/CFD/develop/opt/share/Mesa-7.9.2 --with-x
>> --enable-gl-osmesa --build=x86_64-suse-linux --with-driver=xlib
>> --enable-glu --enable-glw --enable-pic --enable-opengl make -j 4 make
>> install

Though this creates an OSMesa library and a GL library they can not be linked 
together.

I don't remember all of the details but:

    1. long ago OSMesa could be built one of two ways
        1.1 Stand alone OSMesa could not be linked to GL :
offscreen only
        1.2 OSMesa had to be linked to GL : offscreen or onscreen

    2. Now OSMesa can be built only one way which is the same as 1.1.

Paraview has also changed over that time

> Furthermore, the problem does not arise when I am disabling MPI
> support (i.e. VTK_USE_MPI:INTERNAL=OFF)

I can not explain this part.

> I would be very grateful if you could help me find out was I could be doing 
> wrong. Again, the procedure works for paraview v3.8.1, so I am quite at loss 
> when it does not work anymore for paraview v3.10.x.
>
> Please, let me know if you need more information.

Well I need to update the software I have on our cluster anyway.

I might as well do it today.

As I work I'll make a script out of the steps.

I'll share the script with you.

_______________________________________________
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

Reply via email to