From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 4 Feb 2008 03:57:18 +0100 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] A newbie question... Message-ID: <20080204025717.GH15093@nibiru.local> References: <90a5f1175f3b6d1b52ed32839e2f4901@quanstro.net> <9f3897940802030647r4677d1a7y122292d7d51c42cb@mail.gmail.com> <6018296E-43A8-43D5-94C1-6EE4B7CE36B6@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Topicbox-Message-UUID: 42f6fd74-ead3-11e9-9d60-3106f5b1d025 * Filipp Andronov wrote: > Some graphics chip, actually i want port OpenGL to Plan9, > but DRI hasugly architecture and Mesa with X11 are overload > by unnecessary code,as far as i know it is because of historical > reasons. ACK. 3D stuff on *nix is very fat. I wouldn't suggest porting the whole thing, but just leaving the client API. Maybe you could start with specifying an synthetic filesystem which provides the client side functionality, so it's easy to develop an libGL replacement upon that. Feel free to use the OSS-QM resources (eg. the wiki) for that :) BTW: I'm currently doing similar things on the audio front. Maybe you've already seen my posting on the mixer-fs. I'm also working on an Audio-IO-FS. This one should provide an platform and device agnostic interface to audio io devices, so all these APIs out there (alsa userland, esound, ...) can become small and simple adapters to it. > I have experience with X11 and OpenGL specifications and device > driver development, so my plan was port general parts of mesa > (not all of course), but with out DRI on Intel graphics chip > (i have that card) with hardware acceleration. DRI is something which should be far hidden behind clients not even exist within within an client process. AFAIK it's far from being portable (but maybe I'm wrong). > When i start dig problem i have found DRI replacement known as > Gallium3D, it is completely new project (from Mesa community as > far asi know) and it small enough for try to port it. I don't have any experience with this. But from a quick look it might be worth thinking of. Maybe you could start modeling the API's functionality into an filesystem. As an intermediate step you could develop an server for this (maybe using libmixp) on *nix/GNU platforms and connect it from an Plan9 environment (either remotely or from plan9port). So you can develop the Plan9 userland side w/o having the actual drivers ported to Plan9. Once this works and the interface specs are fixed, you could move to native Plan9. At least that's the way *I* would go. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------