Re: [9fans] A newbie question...

["Filipp Andronov" <filipp.andronov@gmail.com>]

> 3D stuff on *nix is very fat.
Yeah. In my point of view modern window system should be build on top
of OpenGL, but X11 build on top of kernel driver and OpenGL add to X11
with "hacks" :)

> DRI is something which should be far hidden behind clients
> not even exist within within an client process
In my point of view DRI should be dead :)
If you look at driver sources you could find many "hacks" and even
code duplications(!). DRI was perfect some years ago, but now it's
something that should stay in history :)


> Maybe you could start modeling the API's functionality into an
> filesystem
I'm not sure now how it should be. There are coupe a questions, so
after some results i will create project on some public host with all
my results and questions about architecture :)

> 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).
I'm even have no Plan9 running setup right now, yesterday i was try to
start it in VMWare, but i failed, today will be new try :)
But it's good thing, try to do it remotely, i'll try this way, thanks :)

> 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.
As far as i think now, in kernel will be only core graphics chip
functions, DRI part and OpenGL implementation should be in users pace.
But Linux goes in different way, so this is point of discussions too
:)

> 2008/2/4, Enrico Weigelt <weigelt@metux.de>:
> * Filipp Andronov <filipp.andronov@gmail.com> 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/
> ---------------------------------------------------------------------
>