[Paraview] Paraview v3.10.1/0 segmentation fault with MPI and MESA support on.

[Albina, Frank]

Hi Kevin!

Thank you very much for the support so far.

What I am trying to achieve is to have:
a) the whole paraview suite, i.e. paraview, pvbatch, pvserver built from scratch.
b) with X, independently of offscreen or onscreen rendering
c) with Mesa using xlib drivers:
   ./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

What I'd like to achieve is a stand-alone paraview version with X support, from which one can start pvserver for performing offscreen rendering via MESA. If one does not start the pvserver remotely, one should still be able to use paraview with onscreen rendering, still using MESA as the rendering engine (i.e. without system OpenGL support, in other words without GPU rendering). Please let me know if this is still unclear.

Following the steps on the paraview WIKI does not seem to work, unless I am mistaken, which I guess I am at the time being. Again, I had had no issues building and running paraview v3.8.1, whereas paraview v3.10.x is giving me a segmentation fault at screen start.

Thank you very much for the script anyway. I sure will make good use of it.

Cheers,

Frank.

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

On 04/19/2011 12:29 PM, Albina, Frank wrote:
> 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.

I build paraview with X and the accelerated drivers for my graphics card and pvserver with OSMesa and MPI.

I start paraview on my workstation and pvserver on our cluster.

> I *should* be able to build paraview with X using offscreen rendering, based on the MESA libraries.

Yes, you can but three of these terms are not precise enough to be useful in this conversation:
  Paraview
    paraview
    pvbatch
    pvserver
  Offscreen
    with X and hardware
    with X
    without X
  Mesa
    hardware accelerated DRI drivers
    xlib drivers
    OSMesa needs GL
    OSMesa conflicts with GL


 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.
>

Parview may have adapted to the requirements of the newer OSMesa Library. I do not really know without knowing *exactly* what you were and are doing.

> If I understood you well, one cannot link an application to libOSMESA.so and libGL.so/libGLU.so at the same time.

Older versions of Mesa could produce an OSMesa library that had to be linked to Mesa's GL library ( so long as that GL library was not built with hardware acceleration support ) *or* they could produce an OSMesa library that did not depend on GL (or X) and could not be linked with any other GL library.

Newer versions of Mesa only produce an OSMesa that does not depend on GL (or X) and can not be linked with any other GL library.

I link to the libGLU.so produced along with libOSMesa.so all the time.

 If this is correct, then it would explain why I get a segmentation fault straight away.

I believe it does.

 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:

That depends.

[ big snip ]

Sorry, I can't really respond to most of that right now.

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

I build the development versions every night so it shouldn't be too much trouble. I'm just putting *everything* together in one script (well really just a sequence of commands) adjusted for release versions, installed to /opt, and so on.