From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 22 Apr 1999 05:33:01 -0700 (PDT)

Mesa/GGI/3D/KGI: a plea for help (was: re: state of GGIMesa)

On Wed, 14 Apr 1999, Aaron Van Couwenberghe wrote:

> On Wed, Apr 14, 1999 at 04:00:54PM -0700, Jon M. Taylor wrote:
> > On Mon, 12 Apr 1999, Marcus Sundberg wrote:
> > 
> > > Paul Fredrickson wrote:
> > > > 
> > > > I've finally got ggi working in a usable configuration and am now looking at
> > > > Mesa.  Mesa has a driver for rendering on GGI, but it doesn't compile.
> > > > There is a note describing a file which is supposed to update the driver for
> > > > the latest version of GGI, but it appears to be empty.  I guess this broke
> > > > because the GGI API has changed (did the ggi_visual struct used to have a
> > > > "fb" framebuffer member? or a ggiGetInfo() function?  I can't find either.)
> > > 
> > > Looks like the GGI Mesa driver is really ancient. Wasn't someone working
> > > on updating this?
> > 
> > 	Yes.  Me.  I have gotten commit privileges to the Mesa CVS tree and 
> > will be doing quite a bit of repair work soon.
> 
> Remember, I hacked GGIMesa into a working state (thanks to help from
> andreas) for Debian packages. Uwe Maurer's latest patch works (I sent it to
> him, a mod of his own) but I messed it up (missing a subdir) and have to
> re-submit it.
> 	If you really want Mesa working on GGI b2 get the source archives
> from your local debian mirror. package name is mesag3+ggi.

	Thanks a million.
 
> But, it's very low quality. 

	Better than what we have now in the Mesa CVS tree which does not 
even compile correctly....

> It acts entirely weird in 24bpp mode, and in all
> others some number of artifacts occur. On top of that, the displaylibs are
> *very* old (still written for ggi 1.0) and as such messes with internal GGI
> state in ways that it shouldn't.

	Fixable.  All of it.  But it will be of small use completely
unaccelerated like it is now.  MesaGGI needs to be made aware of the
existence of extension per-card rasterization libraries which talk to the
KGI drivers directly (or perhaps through yet another LibKGI extension
lib), and those libs need to be written, and the KGI drivers that those
libs encapsulate must also be written.  It will be (and indeed already is)
quite a lot of work, and I could use some help in places - see below.
 
> I'm just glad someone competent (Jon :) is taking it over. I really have
> very little experience writing lowlevel display APIs.

	Well, don't expect too much too soon, I do have some other non-GGI
responsibilities.  But I will do my best of course.  It would be real nice
if someone with a Virge or a CL5465 would step forward to write some
simple 3D accels into their respective KGI drivers.  That way I could be
better able to get broad-based support for different types of hardware
with different acceleration characteristics.  Also I would get the input 
of more people WRT the whole design of the Mesa+GGI+KGI+3D thing, and that 
is always good because solo designers make mistakes and Mesa+GGI+KGI+3D 
thing is _WAY_ too important to GGI, Linux and Creative to leave it 
solely up to my dumb ass |->.

	The CL5465 would probably be the best choice if you want to pick
up a card for 3D hacking, IMHO, for the following reasons:

*  A CL5465-based card can be had for ~$20 if you look around on the net. 
I myself purchased one for that price the other day (AGP, 4MB) to mess
around with a bit.  I think PCI versions are also available.

* Virge has available docs but older S3 hardware is notoriously buggy and
difficult to program.  CL chipsets, on the other hand, are quite well
designed and relatively bug-free.

* CL also pioneered the use of tokenized accel command pipelines in PC
graphics hardware, an approach which most newer 3D accelerators make use
of and which is reflected in the design of the new KGI as well.  The 5465
aint too fast by today's standards but they have more or less the
same featureset as today's accelerators and that is what matters.

* Since Cirrus Logic got out of the PC graphics hardware business a
few years ago to concentrate on signal processing hardware (no doubt
screaming in horror as they went |-/), they have no vested interest in
keeping their specs private and so they can be had in PDF format from CL's
website (www.cirruslogic.com) under 'legacy products'.  Take a look - the
documentation is *excellent* - complete, well laid out, lots of examples
and diagrams, etc.  

* And to top it all off, the existing CL546x KGI driver is also _very_
well written and commented.  Hats off to the authors - that is how driver
code should be written.  Flattish, linear and unconvoluted, heavily
commented and cleanly laid out.  Easy to read, easy to follow.  Hats off
to the author (Chirs Lattner) and the maintainer, Rodolphe Ortalo.  I'm
going to steal their layout for my Creative KGI driver |->.  And if you
guys should happen to want to do some 3D stuff with the CL546x driver,
that would be great for me.

	Anyway, enough of the sales pitch.  it's just that there's a lot
of completely new territory being broken here, and right now I am all
alone out there on the bleeding edge of GGI+Mesa+KGI+3D.  Of course, I
realize that I am getting paid to hack GGI and thus I have less ground to
whine than everyone else (except Stefan - congrats on the job, man!), but
the KGI driver I am working on has been consuming almost all of my spare
cycles at work and I do a lot more than just the KGI driver (SBLive stuff
- a beta OSS driver will be out soon!) and it's been pretty nuts recently.

	There's also the issue of Steffen's new KGI design.  Steffen could
really use some help ironing out the kinks, and I can't develop a new
driver and port it to a different API system at the same time.  I see
posting on ggi-kgi relating to patches and suchlike.  Glad to see that. 
Hopefully Steffen will relent and open up his CVS again if people promise
not to make major changes without his say-so.  Like Andy is with the degas
tree.  That way people will not have to wait for one person to incorporate
patches into the tree.  

	Steffen, would you be willing to consider this?  I ask because the
issue of porting Steffen's new KGI design to KGIcon will be coming up
soon.  The new KGI is sufficiently advanced compared to the old one that
its use will become VERY desireable once the 3D KGI drivers start flying
thick and fast.  Hopefully KGI proper will go into the kernel in v2.3, and
if we have KGIcon set up properly it will be able to arrive with a
kick-ass set of drivers too, both open and closed source. 

	Anyway, it is now very early and I must sign off.  Sorry about the
length of this posting, but it accurately conveys the workload ahead. 
Daryll Strauss called me naive on news:3dfx.linux.glide for promising
creative so much after I go hired and my announcement got posted to
slashdot.  I poo-pooed his concerns at the time, but now I am gaining an 
appreciation for just how much _stuff_ there is in 3D graphics systems!  
i haven't even talked about a lot of my design concepts for the 
individual subsystems of GGI+Mesa+KGI+3D yet.  That stuff will be in 
another posting.  Stay tuned.

Jon "3D graphics is hella complicated but also very very fun" Taylor

P.S. LibGGI3D.  I think its time to put this one on the shelf for a few. 
I have to dedicate myself to getting good, solid GGI_Mesa+KGI+3D working
ASAP, and that means hardwiring dedicated rasterization library extensions
into Mesa for now.  I'll get back to LibGGI3D when we have a solid,
functional and acceptable GGI+Mesa+KGI+3D system in place.  That will be
at least 2-3 months, perhaps more.  We'll see.

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