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]