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.