From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 5 Aug 1999 21:28:19 +0200

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. 

That doesn't help. You need to know the order of the accesses, and often you
will do stuff like:

mov reg#1,commandcode
repnz
	mov reg#2,data[x++]

That doesn't fit well with such a faked accel register mapping.
You are better off to stream such accesses into a simple buffer and execute
that.

>    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? 

This isn't much of a concern. You just need to trap into the kernel. Exact
mechanism isn't very relevant.

> With the idea of a pseudo mmap accel region a msync
> call would actually flush the commands to the kernel. 

As said, this is not possible due to the need to know the order of commands
and rapid overwriting of common registers.

> touched. Now we could something very similar with /dev/gfx. He we mmap the
> psuedo accel buffer and then use msync to actually write the information
> in the mmap to the real file, in this case the accel engine instead of a
> file on the HD. 

See above. Performance will not be worth it.

> Of course if you program say FG_COLOR register and
> reprogram it again then flush you lose the first FG_COLOR information. Of
> course this just requires proper graphics programming. 

A common accel system has some setup registers and an "execute" register.
With your system you would have to flush after each execute, as you would
start to overwrite the setup regs with the next command's arguments after
that. That means a user->kernel->user transition at every command.
We could stay at ioctl for that. Pushing a whole buffer of accesses to the
kernel has less overhead.

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

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

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

It doesn't give much. page-fault is easiest to program in userspace.
You don't care about the buffer edges, you just do something like
"buffer[x++]=cmd;x%=buflen;".

> What about cards that support FIFOs and MMIO registers? 

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

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

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =