[Pkg-ltsp-devel] Wish: Getting VirtualGL into Debian

Alexander Kurtz kurtz.alex at googlemail.com
Wed Apr 22 11:50:45 UTC 2009


Am Mittwoch, den 22.04.2009, 09:13 +0000 schrieb Oliver Grawert:
> just a sidenote, but whats wrong with "real" GL on thin clients ? 
> in ubuntu LTSP (and i'm pretty sure as well in debian since we largely
> share the same LTSP code and have a similar Xorg base) using GL based
> apps on thin clients has worked for ages.
Of course real GL also works, but there are two problems:
1. Not all clients have OpenGL-Support, i.e. a GPU with hardware
   acceleration and the (propietary) drivers installed. Actually I 
   think most have not.
2. The CPU and the GPU of a process are on separate machines, so this 
   will work with simple programs, but don't expect the latest 3D-Game
   to work. Wikipedia has an excellent article about VirtualGL's 
   advantages, see http://en.wikipedia.org/wiki/VirtualGL#The_Problem

> many users use compiz under LTSP in ubuntu, the only problem here is
> that the check mechanism requires to read the Xorg logfile to determine
> if the client is GL capable which in case of LTSP is simply stored
> inaccessible on the client. using SKIP_CHECKS=True for compiz on ubuntu
> LTSP with a GL capable card in the client makes compiz work flawless...
Right, but again: Should a _thin_ client really do something like
rendering OpenGL? Isn't that totally defeating the whole purpose of thin
client computing?

> since i assume even virtual GL needs to know if a client is actually
> capable of doing GL output (else you would just saturate the bandwith by
> shoveling full frames over the network all the time and defeat the
> advantage of GL to just send vector diffs while keeping the bitmaps in
> local videoram), what would be the method to determine GL capability on
> the client ?
No, VirtualGL does not need a GL-capable client. As I said, the OpenGL
calls are catched, rendered on the server's GPU and then send as plain
images to the client. This doesn't eat up your bandwith, as the images
are jpeg-compressed. For example 1280x800 at 30FPS causes about 2-3 MB/s.
If this is too much, you can simply decrease jpeg quality. It should
even be possible via some (fast) DSL connection.

Best regards

Alexander Kurtz

PS: I will send another message containing more general information
shortly!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.alioth.debian.org/pipermail/pkg-ltsp-devel/attachments/20090422/b2e83c8a/attachment.pgp>


More information about the Pkg-ltsp-devel mailing list