Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 12 Aug 1999 16:34:35 -0700 (PDT)

Re: GGI and XFree86 and stuff

On Thu, 12 Aug 1999, Jeff Garzik wrote:

> "Jon M. Taylor" wrote:
> >         Sure, since Trio and Virge also have STREAMS.  The STREAMS is
> > Savage4 is mostly the same.  STREAMS basically gives you another hardware
> > viewport which can address its own linear framebuffer region and can be
> > sized and positioned independently of the primary framebuffer stream.  It
> 
> Could it be used for DGA-in-a-window?

	Sure.  All you'd need to do is point DGA and the STREAMS
descriptor registers at the same chunk of video memory (or system memory
too, on AGP) and have some way to tell STREAMS what the window's
dimensions, size, color format, etc are and off you go. 
 
> >         Actually I have permission to release binaries now, but I haven't
> > run across anyone besides myself who uses KGI and has a Savage4.  Also
> > the 3D accel performance is atrocious right now - since ping-pong buffers
> 
> Why not simply allocate one or two DMA buffers and go with a simple
> scheme until PP bufs arrive.  

1: Hopefully PP buffers will arrive this weekend.  If not I will fall back
to something simpler with explicit userspace command buffer flushes. 
Faster than ioctls but still a lot slower than PP buffers.  I can allocate
larger buffers to compensate somewhat for this, but it is still a stopgap.

2: KGI drivers accept kgicommands, not hardware commands.  Translation is
done in the driver code, which thunks the abstract kgicommands into
hardware commands, which are then put into a DMA buffer or fed into a
hardware FIFO (or a bunch of register-sets are done for really old
hardware).  On good hardware you can pass a lot of the kgicommands through
in the same or very similar formats to the hardware commands, which
lessens the thunking overhead, but anytime userspace could hose the
hardware by sending raw hardware commands with bogus data (which is true
quite often), a sanity checking layer much be present.  That thunking
process is why PP buffers are so useful - since userspace does not have to
do explicit command queue flushing, the thunking can take place
concurrently with userspace command buffer fills.

> You can use the G200-GLX technique of
> reserving memory on bootup specifically for KGIcon, for example
> 'mem=120M' if you have 128MB of RAM.  Then you have a guaranteed 8MB for
> KGIcon to play with.  Anything should be faster than ioctl...

	Since I do not need physically contiguous pages for the kgicommand
buffers, this is not necessary.  And in the KGI driver I can directly map
the hardware MMIO regions, so there is no need to preallocate contiguous
memory at boot time.
 
> >         No, but all the major _families_ are supported, and IIRC all the
> > Pre-Trio chipsets and ramdacs are fully supported.  The Trio64V2,
> > Aurora64, etc are special cases of the existing drivers and would be easy
> > to add support for.
> 
> I am not sure the older 801/805's are supported, but haven't looked
> closely.  All the RAMDACs look to be supported already.  Some of the
> extra code to support 64V2 and A64 should be in s3lib already, as I
> stole it from the XF86 v3 server.
> 
> 
> > > On a related note -- is there any way to get monitor specs out of S3
> > > cards without using BIOS calls?
> > 
> >         VESA DDC.  I have specs as part of the Savage4 docs, but I don't
> > recall if they are otherwise publically accessible.
> 
> AFAIK they are not.

	Oh well.  I'll implement support in the Savage4 KGI driver, which
will at least make it possible to write and test a DDC support _framework_
within KGIcon, so that if/when the DDC specs become available it will be
easier for other people to whip up support in the other KGI drivers.... 
 
> Is DDC possible w/out BIOS?  For example, will DDC code work on Alpha,
> PPC, etc.?  

	It should.  DDC is a simple serial protocol using one of the VGA
pins.

> And is there generic DDC in GGI?  

	Not yet.

> I know there is a bit in
> XF86 but I haven't looked at it.

	How did they do that without specs?

Jon

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

Index: [thread] [date] [subject] [author]