From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/998 Path: news.gmane.org!not-for-mail From: aep Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hello Date: Fri, 08 Jun 2012 14:28:29 +0200 Message-ID: <1cea84019d95a5f03dee3b8f29cc310f@exys.org> References: <20120607200123.402a1672@sibserver.ru> <4FD0A902.6070108@barfooze.de> <20120607231831.66c78c33@sibserver.ru> <4FD0D6D9.5080707@barfooze.de> <20120607161928.GE163@brightrain.aerifal.cx> <20120608011516.0b5fca7d@sibserver.ru> <20120608033141.GH163@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: dough.gmane.org 1339158311 26832 80.91.229.3 (8 Jun 2012 12:25:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jun 2012 12:25:11 +0000 (UTC) To: Original-X-From: musl-return-999-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 08 14:25:11 2012 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 1ScyFW-0004bh-Or for gllmg-musl@plane.gmane.org; Fri, 08 Jun 2012 14:25:06 +0200 Original-Received: (qmail 15593 invoked by uid 550); 8 Jun 2012 12:25: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 15585 invoked from network); 8 Jun 2012 12:25:06 -0000 In-Reply-To: <20120608033141.GH163@brightrain.aerifal.cx> X-Sender: aep@exys.org User-Agent: Roundcube Webmail/0.5.4 Xref: news.gmane.org gmane.linux.lib.musl.general:998 Archived-At: > Unless reading video memory has gotten substantially faster Not in hardware, but the new DRI interface in the kernel made graphics in linux much much less shitty. > The way the X server is written, almost all common operations require > reading back from video memory if implemented in software This is because X is a network protocol, not a graphics stack. The fix is to emulate X11 on top of a real graphics architecture, namely DRI. The only implementation i know is wayland. Either way, the 1960 way of accessing GPU commandbuffers in userspace is a dead end. > By changing the implementation to do everything on a > mirrored buffer in main memory Correct. Afaik this is what XComposite in vesa already does, and llvmpipe can operate very effiently on DRM shares in main memory. You can even play quake3 on an arm cortex A9 with llvmpipe, it's right on my desk. But those things are 2012 technology, and they come at a price of a pile of dirt below them, with horribly broken build systems and misinterpreted "portability" issues. Getting a real GFX stack on top of any musl-only distro is going to be a long walk. On Thu, 7 Jun 2012 23:31:41 -0400, Rich Felker wrote: > On Fri, Jun 08, 2012 at 01:15:16AM +0800, orc wrote: >> On Thu, 7 Jun 2012 12:19:28 -0400 >> Rich Felker wrote: >> >> > As far as the server goes, even the oldest X server versions >> should >> > work fine with modern software (aside from possibly being really >> slow >> > when the software wants to do 3D, etc.). That's how X was >> designed. >> > >> Of course we need modern X11libs for that. But yes, server expects >> only >> Xau, Xdmcp, crypto for ssl (modern X links to stuff like udev, >> pixman >> and others, but this can be avoided). >> When building and running X I got only one thing: for 3D, games and >> so >> on I need a dedicated machine with videoboard vendor's drivers (no >> matter opensource it or proprietary). For anything else, I would use >> vesa. > Unless reading video memory has gotten substantially faster (i.e. the > same speed as main memory) I don't think vesa suffices for ANY use. > The way the X server is written, almost all common operations require > reading back from video memory if implemented in software. This could > be avoided by changing the implementation to do everything on a > mirrored buffer in main memory and only copy the final version to > video memory, but as far as I know that was never done. > > If I'm wrong and video memory access issues have changed all this > much > in the past 4 or 5 years, please ignore this message... > >> So there is a question: will musl support this configs? Or I will >> need patchelf and 'libc6-legacy' for them? > > It's intended to work, but I don't know whether it does yet. > > Rich