From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 19 Aug 1999 00:04:51 -0700 (PDT)

Re: VC Switching

On Thu, 19 Aug 1999, Andrew Apted wrote:

> Brian writes:
> 
> >  But, you have good arguments in favor of a sane vc-switching system.
> >  They seem to reinforce the point that the graphics card needs
> >  to be viewed as a resource server, serving up frames, sprites, 
> >  textures, and whatnot, and not seen as a single resource; except for 
> >  the actual focus (of which there is only one per monitor attached 
> >  to the card, so those are single resources.)
> >  
> >  We should do the vc-switching system *right* even if it means
> >  hacking it out entirely and putting it off for a while.
>  
> In my opinion, doing it *right* means not doing it in the kernel at
> all.  A kernel should just be managing the devices (such as video
> cards with whopping big memories), and allowing userspace to allocate,
> deallocate & use the resources, but not implementing user interface
> abstractions like VTs.

	At least not unless all the loose corners are tied down....

> Imagine if an X server emulated the text consoles (and there's no
> reason why it couldn't AFAIK).  It would be indistinguishable from the
> current system.  I'm not advocating that BTW :->, but I think it
> points the way to how it *should* be done.

	It could easily be.  Just have fbcon-kgi.c trap the VT switch and
*not let it happen*!  Instead, switch to another "virtual VC" and keep the
kernel mapped to VC1.  We should be able to implement our own system on top
of fbcon-kgi.c, perhaps even Steffen's KGI console subsystem. 
 
> And while I'm playing Devil's Advocate...  Ping Pong buffers.  I
> understand how they work, but not _why_ to go to the extra trouble of
> using page faults, instead of just calling some write() function which
> can pass a big block of accel commands to the driver.  What is their
> advantage ?

1: You can map and use huge FIFO spaces while only having to allocate a small
number of physical pages.  Try allocating 64MB of FIFO buffer in the kernel
using kmalloc().  These larger spaces increase speed by decreasing the number
of times your userspace process takes a _real_ pagefault when it runs off the
end of the virtual FIFO, which requires a signal to userspace in order to
activate a fifo-counter-reset signal handler, an indeterminate amount of time
while waiting for the signal to be delivered, the stall and reset overhead of
the userspace FIFO manager thread, and the in-kernel signaling overhead
itself.  You don't want to impose that kind of penalty against a high-speed
I/O channel any more often than you absolutely have to, and the bigger the
FIFO space the less often it will happen.  Of couse there is a dropoff in
return, I assume, but I don't know where the sweet spot is and I'll bet it
varies based on CPU type, speed, cache type and settings, etc.

2: In theory the page fault 'trap gate' can be much faster than the kernel
syscall 'call gate'.  This is both because neither the kernel not the CPU
itself have to deal with the overhead of passing parameters into the kernel. 
Right now the KGIcon trap gate is a little slower than a ioctl() call gate
because it is unoptimized, but that will change soon.  This should be even
more efficient on Intel's 4MB pages (although latency might be too high
there) or on architectures like the alpha(?) which can change their page
sizes.  An interrupt-based trap gate would be faster still, but I can see of
no way to trigger an interrupt by writing to a particular memory location...? 

3: The userspace buffer-filling code can just set a pointer to the beginning
of the FIFO space and start writing in an extremely tight loop, being fed by
another thread which (in the case of Mesa) is probably processing entries in
a vertex buffer.  When you have an explicit-flush type of system such as you
described, however, the writer process has to check for end-of-buffer 
every time around the loop.

Jon

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