* Filipp Andronov <[EMAIL PROTECTED]> 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/
---------------------------------------------------------------------

Reply via email to