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:[email protected]] On Behalf Of Lloyd Brown > Sent: Wednesday, March 30, 2016 1:37 PM > To: [email protected] > 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
