Can I run GLU (OpenGL) on a headless server?_问答_开发者

we're trying to us开发者_运维问答e GLU's tesselation functions on a headless, GNU/linux server. We'd like to use PyOpenGL for that, but the problem is that it crashes on a call to gluNewTess (Segmentation fault)

gdb backtrace says it's in glGetError, that makes me think that GLU tesselation needs a GL context? Or is it just some intricacy in PyOpenGL?

I tried to find some information on how to initialize GL context on a headless (and virtualized) machine, no luck. Any information on these topics is appreciated.

easiest:

Xvfb :5 -screen 0 800x600x24 &
export DISPLAY=:5
glxgears

instead of glxgears, replace with your program, and stick a 'glutInit()' into your python code to get a basic GL window.

harder:

rewrite your program to create an GL context using the OSMesa library

hardest:

rip the guts out of the GLU tesselator and stick it in your project (download the MesaLib source code)

I experimented with this and yes, it appears that you can. I managed to get it working under Docker.

For me, the trick was to run the following:

RUN apt-get update && apt-get -y install libgl1 freeglut3-dev xvfb
RUN pip install -r requirements.txt
ENTRYPOINT xvfb-run -s '-screen 0 1024x768x24' ./main.py

Note that this only allows software rendering - while it might be good enough for my project, it might not be for yours.

Most of the options at VJovic's link aren't hardware accelerated and all of them are deprecated in favor of the OpenGL Framebuffer Object extension (Notice the date: 1997!). Also, offscreen rendering isn't the whole solution, as Calvin1602 noted, you need an openGL context (except for OSMesa, which uses software rendering).

Our research lab has been doing headless opengl rendering for about a year (you can see my related serverfault question here), and we found that the easiest thing was to just give users remote access to the server's local X-screen. The downsides: (a) giving remote access to the x-server is regarded by some as a bad security practice if done wrong, and (b) it opens a dummy window will pop up on the server's display, but if it's headless, this shouldn't matter. A few other options are described in the ServerFault link too, if you're interested.

You need an x-screen running on the server, and it should be noted that some video cards require a physical monitor to be attached if you want to start an x-screen. The NVidia driver lets you get around this using the ConnectedMonitor option in xorg.conf.. Another option I've used in the past is to the build a dummy monitor plug. that makes the system think there's a CRT monitor attached. There are probably other solutions.

Good Luck!

https://serverfault.com/questions/186805/remote-offscreen-rendering

You can do off-screen rendering. More about it here.

It depends what is supported by your graphical card and the OS. If you got old graphical chip, you can use mesa OS library (but you get software rendering). If it is newer, you can use pbuffers.

I've been using glu tesselator without OpenGL context for a while, this works on Windows and Linux (not with python, but C++), so it is in theory possible. If you setup the error callbacks in gluTessCallback() see red book it probably will not call glGetError.

GLU requires a valid openGL context, yes (even if it should be possible to call the tesselator alone withoug a context).

If you don't have a window, it should be possible - but hard. See the opengl wiki (and read it 3 times, it's quite hard to follow).

The basic idea is that you need a special extension to create your special, window-less context. Thus you have to call wglGetExtensionsStringARB to get this extension. But to be able to call it, you have to have a context in the first place ! ( yes, this is a nightmare. I have whoever created this api ). So create a context the usual way ( and hope that it works even it you don't have a screen ), get your extension, call wglCreateContextAttribsARB

Note : the extension spec says that When this extension is supported, calling wglCreateContext(hdc) is equivalent to calling wglCreateContextAttribs(hdc,0,NULL), so maybe, maybe you could bet along with a simple context creation.