Network protocol, service, and API for using OpenGL remotely.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
data
docs
gleri
test
tut
.gitignore
Config.mk.in
LICENSE
Makefile
README
config.h.in
configure
gleri.h
gleris.cc
gleris.h
gob.cc
gob.h
gofont.cc
gofont.h
goshad.cc
goshad.h
gotex.cc
gotex.h
gwin.cc
gwin.h
iconn.cc
iconn.h
xkeymap.h

README

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

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

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

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