[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140904151709.GA1780@newbook>
Date: Thu, 4 Sep 2014 08:17:09 -0700
From: Isaac Dunham <ibid.ag@...il.com>
To: musl@...ts.openwall.com
Subject: Re: libhybris and musl?
On Wed, Sep 03, 2014 at 06:59:17PM -0400, Rich Felker wrote:
> Basically, my view, as expressed many times on #musl, is that all of
> the existing GL drivers, but especially the non-free ones, are full of
> way too much bad code to be safe to load into your program's address
> space. Any process that's loaded them should be treated as potentially
> crashing or aborting at any time, and possibly also has serious
> namespace pollution from random libs getting pulled in.
>
> The way I'd like to see this solved for our "new platform vision" is
> to move the actual GL implementation out of the address space of the
> application using it, and instead provide a universal libGL for
> applications to link (even statically, if desired) that marshals all
> GL operations over shared-memory-based IPC to a separate process which
> has loaded the actual driver for the target hardware you want to
> render to. As long as the IPC tools used don't depend on a particular
> libc's ABI at all, this should make it trivial to solve the problem
> libhybris aimed to solve at the same time: you simply use Bionic in
> the GL driver process, and your preferred libc with the application
> side libGL.
I saw an implementation of GL based on this design or something very
similar recently.
The point the developer had was to make a GL that could be statically
linked and handle remote rendering.
Ah yes, there it is:
https://github.com/msharov/gleri
"Network protocol, service, and API for using OpenGL remotely."
HTH,
Isaac Dunham
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
