msharov / Gleri

=============================================================================

                   ####  #     ####  ####  ####
                   #     #     #     #  #   ##
                   #     #     ##    ####   ##
                   #  #  #     #     # #    ##
                   ####  ####  ####  #  #  ####

=============================================================================

1. OpenGL Blues

If you are writing a graphical application on Linux and want it to take advantage of GPU hardware that every computer has these days, your only option is to use OpenGL, because that is the only API exposed by the drivers. Unfortunately, using OpenGL is not without its problems.

The most acute problem is inability to run your applications remotely. X and Unix in general have a long history of allowing remote use, a very useful capability in many circumstances, but while there is an X extension (GLX) allowing OpenGL remoting, it is restricted to the ancient version 1.2 API that does not support essential capabilities such as vertex buffer objects. Furthermore, GLX is at this time being deprecated in favor of EGL, and will be replaced by it in some near future. Even worse, the entire X11 protocol is in danger of disappearing and being replaced by Wayland, which is not designed for remote use.

Another problem is the libraritis infection you get by having to link to the OpenGL shared library. No static library is available for this, so no statically linked executables can be created. The OpenGL library is huge and contains a lot of low-level tie-ins to the kernel driver guts, resulting in bloat and instability. Crashing your application may cause a kernel panic, just like in good old Windows 3.1, which likewise made the mistake of putting driver guts into user application process space. The driver initialization sequence can also be slow (~.3s), and must be done every time you start your application.

Finally, one must mention the problem of debugging an OpenGL application. If you happen to hit a breakpoint at some location unexpected by the driver developers, sometimes you would not be able to switch to the debugger because you've just trapped something critical in the driver and stopped all X rendering. Often, this situation requires a hard power cycle. After a while you give up trying the debugger at all.

Now, wouldn't it be nice if there was a network protocol letting us write applications that use OpenGL remotely, without linking to the entire graphics driver? Well, GLERI is it.

2. GLERI

GLERI is a library implementing an OpenGL functionality service and a protocol for communicating with it. This allows creation of executables that do not have to link with OpenGL libraries, have direct access to the DRI devices, or require a local X11 connection.

The service is called gleris and can be used either standalone, or be launched individually by libgleri-using applications. By default, only the local $HOME/.config/gleris.socket is created. If you want a TCP socket, run gleris -t, which will make it listen on localhost port 6540+display. Alternatively, you can use systemd socket activation to create appropriate sockets and have them passed to gleris automatically.

You can then forward that port with ssh to wherever with the ssh -R command. When you do this, you'll need to also copy the xauth token and set DISPLAY (or GLERI_DISPLAY if you are already forwarding X with ssh -X) to match it on the server. gleris will load the xauth token for the display it is running on, and can not read the xauth token generated by ssh -X, because that token is only used inside ssh. So you need to set the display variable to the same value gleris sees.

The library is libgleri.a, See the test/ program for a usage example.

The target platform is a POSIX compliant architecture, such as Linux or BSD. Windows and embedded platforms are absolutely not supported. Other minimum requirements are Linux kernel 2.6.28, GCC 4.6 or clang++ 3.2. Wayland will likely be supported in the future when it supports OpenGL (currently it only has OpenGL ES support). Required libraries are zlib, libpng, and libjpeg.

OpenGL 3.3+ is required. The current open source drivers support it on Intel hardware since Mesa 10.1 and radeon and noveau since 10.2. Binary drivers, however, still deliver the best results for nVidia.

To build: ./configure && make To install: make install Test program: make check Documentation: docs/ Tutorials: tut/

3. Acknowledgements

gleris embeds the Terminus font for default text output test program princess spritesheet is from opengameart.org