[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 28 Apr 2013 14:53:44 +0800
From: Muhammad Sumyandityo Noor <lynxluna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: High-priority library replacements?
Rich Felker wrote:
> On Fri, Apr 26, 2013 at 07:57:36PM +0700, Muhammad Sumyandityo Noor wrote:
>> You meant replacement for Mesa? Because TinyGL is software renderer.
>> It's unlikely people will utilize software renderer. As for embedded
>> system, each SoCs provides their own userland to utilize its
>> hardware accelerator.
>
> I don't really understand the GL architecture presently in use well
> enough to know the right solutions, but if I'm not mistaken, it
> involves loading dynamic modules, possibly even binaryware
> hardware-vendor-provided ones, into the address space of your
> application. This seems like a recipe for disaster.
OpenGL support varies from platforms to platforms. On Windows, for
example, M$ will use software renderer via OpenGL32.dll if the ICD
(Installable Client Driver) is not present. If the driver is installed
(e.g. from nVidia or ATI), the call to OpenGL32.dll will be redirected
to the ICD libraries automatically.
On Linux, especially on embedded space. The SoC manufacturer usually
ships open source kernel driver to create a device nodes and communicate
with it. I'll take PowerVR SGX by imagination as an example. They have
open source driver to create /dev/pvrsvrkm device node. The bulk of
graphics operation however, lies in userland (non-open source) library
(libEGL.so and libGLES**.so). This library communicates with the device
nodes by uploading some (another proprietary) 'firmware' to the GPU, and
then communicates with device nodes via ioctl with protocol that is
proprietary too.
So, as you have said it is a big mess.
(http://www.phoronix.com/scan.php?page=news_item&px=ODk0NA) the article
published in 2010 and still true even for today.
>
> Software-rendered GL is definitely not the solution, but I wonder if
> it would be reasonable to create a library that provides the OpenGL
> API with NO namespace pollution or introduction of dangerous code into
> the application's address space, by cooperating with a separate
> process via shared memory. On modern Linux, this separate process
> could use Linux namespaces to completely throw away all privileges
> except to the graphics device. Then the nasty legacy OpenGL code could
> run in a sandbox.
Pardon for my limited understanding of this matter. But if you mean
replacing manufacturer-provided libEGL.so and libGLES**.so, then I don't
think it's possible, as many parts of it are hidden. And to separate
that to another process, I don't think OpenGL Context can be shared to
another process or created without referencing to libEGL.
> Rich
I'm very new in linux system programming. It's based of my (very)
limited knowledge of how OpenGL ES works in embedded device.
Thanks,
Muhammad Sumyandityo Noor (Didiet)
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.
