Re: High-priority library replacements?

[Muhammad Sumyandityo Noor <lynxluna@gmail.com>]

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)