Index: [thread] [date] [subject] [author]
  From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 9 Aug 1999 14:02:27 +0200 (CEST)

Re: Matrox GGI accellerator

> On Tue, 3 Aug 1999, Steffen Seeger wrote:
> 
> > James Simmons wrote:
> >  
> > > > I really think that pingpong buffers are the best way to go, given the graphic
> > > > card hardware problems that prevent us to mmap fully to userspace without
> > > > compromising safety on the one hand, and the latency of ioctl on the other
> > > > hand (this is not to neglect even if I agree that ioctl are not so bad
> > > > in practice - especially for 2d ops.).
> > > 
> > > Hum. Can you expalin in detail the ping pong method. I sort of have a
> > > idea on how it works but not quite. Thanks.
> > 
> > You just expose a hardware command buffer to the application which 
> > 'compiles' commands into that buffer. Once the buffer is full, you
> > deny the application access to it, and give it to the driver to 
> > 'execute it'. This means either to start a DMA transfer of the buffer,
> > do programmed IO to send the commands to the hardware. This allows all
> > the API specific translation of rendering requests to be translated into
> > a hardware specific command stream by userspace code. This is why we have
> > to consider a modular library like libGGI as a part of the driver.
> > 
> > The tricky thing about this is just how to detect if the buffer is full
> > and when to switch buffers, do context switches etc.. This is worked 
> > out at code level and already implemented in KGI-0.9. The parts are 
> > tested independently, but the whole thing is not due to lack of drivers
> > and time to finish those. It does (in a quite simple but extendible manner)
> > what you are trying to implement: virtual graphics processors.
> 
> Do you mean with "graphic processor" the chip, which draws things on the
> screen, OR do you mean a geometric processor like the OXYGEN GVX1 has?
> BTW: I know what you want to say with "virtual".

I refer to the chip as a whole. This may include a geometry processor as part
of the ´command/instruction processing pipeline´. Just think of the commands
sent to the chip as instructions to be executed by the graphics processing 
unit (GPU).

 
			Steffen

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------

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