[Paraview] [EXTERNAL] BadAlloc Error

Thu Mar 31 23:10:35 EDT 2016

Hi Lloyd,

If you've built ParaView yourself in the past then doing it with EGL
support shouldn't be any more difficult. The link that Utkarsh sent out
covers most if not all of the necessary information. I'll highlight the
fact though that you'll need to update your NVIDIA drivers to at least
355.11. The dashboard that's testing ParaView with EGL is running 358.13.

If you're building 5.0 or 5.0.1 it may not have the newest stuff for easily
finding EGL libraries. For reference, on our EGL dashboard machine the
location that the default NVIDIA driver install puts the EGL libraries and
header files are:
 EGL_INCLUDE_DIR                  /usr/include
 EGL_LIBRARY                      /usr/lib/x86_64-linux-gnu/libEGL.so
 EGL_gldispatch_LIBRARY
/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
 EGL_opengl_LIBRARY               /usr/lib/x86_64-linux-gnu/libOpenGL.so

Please let us know if you have any problems.

Best,
Andy

On Thu, Mar 31, 2016 at 4:51 PM, Utkarsh Ayachit <
utkarsh.ayachit at kitware.com> wrote:

> Lloyd,
>
> For a headless server with K80s, you cannot use binaries distributed
> from paraview.org. I'd suggesting building ParaView from source with
> EGL support (refer to
>
> https://blog.kitware.com/off-screen-rendering-through-the-native-platform-interface-egl/
> ).
>
> Andy, can you point Lloyd to any addition ParaVIew + EGL build
> information that may be useful? Thanks
>
> Utkarsh
>
>
> On Thu, Mar 31, 2016 at 10:36 AM, Lloyd Brown <lloyd_brown at byu.edu> wrote:
> > Well....not exactly.  Just for clarification, this is running pvserver,
> > with a completely headless Xorg instance.  I'm then connecting my
> > desktop's Paraview frontend instance to it over (presumably) a TCP
> > socket.  I'm not actually using SSH x11 forwarding, in this case.
> >
> > But to answer your other question, here's the similar info from my setup:
> >
> >> bash-4.1$ DISPLAY=:0.0 glxinfo | grep OpenGL
> >> OpenGL vendor string: NVIDIA Corporation
> >> OpenGL renderer string: Tesla K80/PCIe/SSE2
> >> OpenGL version string: 4.5.0 NVIDIA 352.79
> >> OpenGL shading language version string: 4.50 NVIDIA
> >> OpenGL extensions:
> >> bash-4.1$
> >
> > So, if I'm interpreting that right, I should be able up to handle OpenGL
> > v4.5.0.
> >
> > Lloyd
> >
> >
> > On 03/30/2016 08:25 PM, Scott, W Alan wrote:
> >> Lloyd,
> >> I see the same thing,  ... um ... sort of.  Mine occurs when ssh -X'ing
> into a remote blade.  New ParaView (i.e., 5.0.0 and later) needs OpenGL
> 3.2.  I suspect that X forwarding isn't supporting OpenGL 3.2.
> >>
> >> If I log onto the blade directly, the OGL version is sufficient.  But,
> when ssh -X'ing into it, if I do a "glxinfo | grep OpenGL", three of the
> lines will say
> >>
> >> OpenGL vendor string: NVIDIA Corporation
> >> OpenGL renderer string: Quadro 3000M/PCIe/SSE2
> >> OpenGL version string: 2.1.2 NVIDIA 337.25
> >>
> >> I wonder if you aren't seeing the same thing?
> >>
> >>
> >> -----Original Message-----
> >> From: ParaView [mailto:paraview-bounces at paraview.org] On Behalf Of
> Lloyd Brown
> >> Sent: Wednesday, March 30, 2016 1:37 PM
> >> To: paraview at paraview.org
> >> Subject: [EXTERNAL] [Paraview] BadAlloc Error
> >>
> >> Hi, all.
> >>
> >> I'm trying to get Paraview 5.0 to interact well with the Tesla k80 GPUs
> in my HPC lab, and I'm encountering an interesting error.  I'm hoping that
> someone can point me in the right direction to diagnose it.
> >>
> >> So, on an HPC node, with some k80s installed, I'm launching Xorg
> (example config attached) as root, then launching pvserver
> >> ("DISPLAY=:0.0 pvserver") as my user.  Then when I try to connect from
> the Paraview frontend on my desktop, pvserver exits with this error:
> >>
> >>> Waiting for client...
> >>> Connection URL: cs://m8g-1-5:11111
> >>> Accepting connection(s): m8g-1-5:11111 Client connected.
> >>> X Error of failed request:  BadAlloc (insufficient resources for
> >>> operation)
> >>>   Major opcode of failed request:  135 (GLX)
> >>>   Minor opcode of failed request:  34 ()
> >>>   Serial number of failed request:  26
> >>>   Current serial number in output stream:  27
> >> Now, according to the guys on the xorg users list (
> https://lists.x.org/archives/xorg/2016-March/057984.html), this is
> occurring as a result of the glXCreateContextAttribsARB call getting denied
> resources somehow, which lines up with the backtrace from gdb (also
> attached).
> >>
> >> Now, under the assumption that pvserver was somehow running out of
> memory, I've verified that the problem still occurs when my HPC job
> requests 64GB (which means the cgroup will limit me to that).
> >>
> >> Since both the client and server are precompiled 5.0 binaries from
> paraview.org, I'm not entirely sure where to go here.  Can anyone shed
> any insight on what might be going on?  A misconfiguration in my Xorg
> config?  Some software package I'm missing?
> >>
> >> It's worth noting that several GLX-based benchmarks (eg. glxgears,
> glxspheres64, glmark2) and utilities (eg. glxinfo, glewinfo) seem to be
> able to interact with the Xorg just fine.
> >>
> >> Thanks,
> >>
> >> --
> >> Lloyd Brown
> >> Systems Administrator
> >> Fulton Supercomputing Lab
> >> Brigham Young University
> >> http://marylou.byu.edu
> >>
> >
> > --
> > Lloyd Brown
> > Systems Administrator
> > Fulton Supercomputing Lab
> > Brigham Young University
> > http://marylou.byu.edu
> >
> > _______________________________________________
> > 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
> >
> > Search the list archives at: http://markmail.org/search/?q=ParaView
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/paraview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160331/70e77c53/attachment.html>