From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3230 Path: news.gmane.org!not-for-mail From: Muhammad Sumyandityo Noor Newsgroups: gmane.linux.lib.musl.general Subject: Re: High-priority library replacements? Date: Sun, 28 Apr 2013 14:53:44 +0800 Message-ID: <517CC778.3030402@gmail.com> References: <20130425041553.GA13951@brightrain.aerifal.cx> <20130425211914.2d98535d.idunham@lavabit.com> <517A79C0.50502@gmail.com> <20130426155305.GR20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367132048 7440 80.91.229.3 (28 Apr 2013 06:54:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Apr 2013 06:54:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3234-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 28 08:54:09 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UWLUt-0001AB-OY for gllmg-musl@plane.gmane.org; Sun, 28 Apr 2013 08:54:07 +0200 Original-Received: (qmail 20035 invoked by uid 550); 28 Apr 2013 06:54:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20027 invoked from network); 28 Apr 2013 06:54:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NqByoPuhLClxoXA3gPoQNlzJ7vji7WR73a2AYVS+VJw=; b=SL63breVgk1tupRCSaJOpY/8SWIZhUDEgQI7fF615MKsV/OY5OX5r3YvvL2/bekH3Q 7KJeO/T9POrVdW0VgPV9EM1x5HUihnC8He3UEP/pcAqF/PDWwsFLUL5bOrgYojY9ame6 9HiUNtkNkxsXNgKiUhzHPYWbYaDxHt2xajjSAdIWaom7DaBpI0T4DDDz0OglwoEyPmxr 10jlhHMHmqRrOVGrWbV0ItqdyRd6oXfsXUjwzbcaEnl3Aw+Si2chpegEYSOmj7Pz2NGn fq5lKS5moCvRgfOYI/HQrNDGHxtgxM2qFtbesMSxxwGu6ewkA8vxPhnIbpC4whDNAT2d 5c7Q== X-Received: by 10.68.58.228 with SMTP id u4mr53780884pbq.30.1367132033979; Sat, 27 Apr 2013 23:53:53 -0700 (PDT) User-Agent: Postbox 3.0.7 (Windows/20130120) In-Reply-To: <20130426155305.GR20323@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:3230 Archived-At: 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)