From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 5 Aug 1999 11:16:47 +0200 (CEST)

Re: Accels and /dev/gfx.

 
>   Wow!! What a long and great thread. Well the ping pong buffer sounds
> like the way to go. I though about the generic buffer commands. Its would
> bloat the drivers to much. What I was think of was mapping a clone of
> accel register space to userland. A regular piece of memmory. LibGGI
> should take care of the translations of graphics functions like Triangle
> to which register. As pointed out for some cards this would be to much of
> a mess and would have impact on performace if we place this into the
> kernel. Good example was the Virge card. First we would filter any bad
> commands then we would swap that memory into kernel space. 

The ping-pong buffers are just that, but a lot faster and more flexible.

>    As for the flushing of the accel commands before the ping pong buffers
> are full. I saw alot of people discussing a a ioctl for this. Why? Did you
> forget about msync? With the idea of a pseudo mmap accel region a msync
> call would actually flush the commands to the kernel.

See my other mail about the refined ping-pong buffer handling in KGI-0.9.
This problem has already been solved.

>   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? 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? Now for the page fault method. Well if its
> just a mmap of psuedo MMIO registers is the page fault method the best
> method or just using msync.

I doubt this will be fast enough to be useable.

> For things like FIFOs which I believe use 
> waterlevel irqs should we use a empty msync function. What about cards
> that support FIFOs and MMIO registers? We need to really group together
> all the possiblities. 

>   As for using no_page for ping pong buffers. Yes you can. The nopage
> function can also control the write access of these pages. I wonder if the 
> protect and advise functions are now used for vma_ops. You have to be
> careful with using nopage and mmap. You need to make sure not to call
> extensively remap_page_range from fops->mmap. Here is a example of how
> to set it up 

That's why we have a pretty fast fast_remap_page_range() thanks to Andy.
This does only what's neccessary and improved performance of the mapping
code quite a lot. BTW, KGI-0.9 uses the no-page handler to implement this.

> If nopage method is left NULL the kernel code that handles pages faults
> maps the zero page to the faulty virtual address. Therefore if you call
> mremap and their is no nopage you end up with zero pages instead of a seg
> fault. The above code is a example and I'm tired. A better way would be
> memory emthod directly returned the physical address, bypassing
> remap_page_range. 

I suggest you have a close look at the /dev/graphic device file driver
(external mapper) in a recent kgi-0.9 snapshot. This implements all this
already. I haven't cared about SMP yet, but the basic mechanisms are
worked out and tested.

> P.S.
>   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.

These have been my words for ages...

> P.S.S 
>   The console code. Well it me verses Mares. Mares believes you can do
> multiheadedness with the current console code. 

I would not say impossible, but I would like to see something
like the KGI-0.9 compatibility layer before I believe it.

> He thinks all that needs to
> be done was a few lines of code to be changes. I told he was nuts. He
> also wants to impliment explict locking of the VT for VT switching. You
> need to lock the VT manually before you do a console switch. Then you
> unlock the VT after th console switch. He thinks this will cure all the
> race conditions that can occur with the current console code.

I doubt that as well, but if he can prove his statement...
I'll use my time to finish KGI-0.9.

			Steffen

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