Index: [thread] [date] [subject] [author]
  From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 6 Aug 1999 10:02:22 -0400 (EDT)

Re: Accels and /dev/gfx.

Okay the psuedo accel buffer idea sucked. Thansk for pointing it out.

> >   What we really need to do is ask ourselves what are all the possible
> > ways accel information can be passed to the kernel and do all of these
> > work well with ping pong buffers. From what I can see you have FIFOs,
> > DMAs, and plain MMIO registers. Did I miss any? 
> 
> That is the most common stuff, yes. Anything else is exotic or very similar
> in nature.

I never programmed a FIFO. I have docs on the ATI 64 cards which use a
FIFO. This way I can get a feel of how to program one.

> > The next question is what
> > can trigger a flush of the ping pong buffers. Their is of course the
> > manual way. Then their is waterlevel irqs, vbl. Any others beside the
> > page fault method I missed? 
> 
> Seems o.k. - process switch might be one, if you use multiple virtual accel
> engines.

Oops. Forgot the most important one. Actually if I start out /dev/gfx with
multiple virtual accel engines then process switching could actually be
the method to flush the ping pong buffers instead of the page fault
method. This would only work if process switching occurs. Are their any
times when process switching does not occur under linux like single user
mode? I believe it always occurs. 

> That is usually synchronized. That is, the MMIO-register accesses are
> FIFOed.

Okay. I need to read some docs on FIFOs and DMA programming of the accel
engine. 

> >   Kernel side. After much debate I believe I have won the debate on VC
> > switching and /dev/fb. On a open(/dev/fb..) VC switching will be disabled
> > in 2.3.x kernels. They realize that with the upcoming cards demanding
> > userland applications to catch VT switchings and saving the framebuffer is
> > going to be impratical. 
> 
> Good and not good as well. IMHO a VT switch should be pretty mandatory, but
> better than having a mess like now.

The problem is with mmap. With large framebuffers (> 32 Megs) its just
going to become impratical. 
 
> >   The console code. Well it me verses Mares. Mares believes you can do
> > multiheadedness with the current console code. He thinks all that needs to
> > be done was a few lines of code to be changes. 
> Let him do it. Let him show.

Let him try. /dev/gfx is more important to me. Once I'm done I will go fix
his work.

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