On Mon, 13 Dec 1999, teunis wrote:

> Anyways as far as I know (and I don't know much):
> - 3D accel within GGI is currently targetted at writing hw
>   drivers for Mesa.

        HW drivers _at all_ |->.  Right now Steffen and I are working on
the new KGI-0.9 system with Permedia2 as the reference driver.  This also
means that when the driver starts being able to draw some triangles, the
target code I'll be working on will be KGI-0.9 target code.

>       -> wonder if a fbdev/glide Mesa driver could be done?  Then run an
>          X that runs under that....

        There is already a lot of good Glide driver code for Mesa.  Since
a nice Glide target for LibGGI already exists, this would provide an
_excellent_ way to exercise the GGIMesa-overloads-LiBGGI-targetcode system
that we are trying to get off the ground here.  You could probably steal
90% of the code from the existing FXMesa code.

> - 2D accel is limited

        Almost nonexistent.  The Berlin guys are starting to use LibGGI2D
heavily, so hopefully it will improve and then we can easily code up some
LibGGI2D target code for GGIMesa.

> - non-video buffers within the videocard (ie Z-buffers) are
>   afaik accounted for within the directbuffer api specs
>   but also afaik nobody's bothered writing an
>   implementation....

        Not yet.

> - AGP should be handled by some sort of libAGP extension.  I
>   haven't seen even a proposal for how this should be done.
>   Incidentally, the 3Dfx driver seems to have AGP support...

        AGP is a little ways off.  You can play with the /dev/agpgart
support in the new 2.3.x kernels.
 
> A big problem I've found with the GGI project is that noone really knows
> how acceleration -should- be handled between kernel and userspace.  

        In general, I support ping-pong buffering as the best method.

> or
> even which methods are most appropriate.  

        Well, obviously the target code must conform to the system it is
targeting, so unless your system supports PP buffering (i.e. everything
but KGI) you'll not be able to use it.  So LibGGI cannot be tied to any
one type of accels communcation system.

> And many of the interfaces
> developed (ping/pong buffers as an example) are either currently unusable
> or not really tested all that much.  I'd -love- to see some sort of formal
> FAQ/RFC on this issue...  anyone?  

        Lots of mailing list posts, plus I wrote up a detailed explanation
of PP bufs for John Carmack once.  I'll try to pull all of this togther
into a comprehensive FAQ when I have some time.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
        - Scientist G. Richard Seed

Reply via email to