From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Fri, 6 Aug 1999 09:29:21 -0400 (EDT)

Re: GL, X, accel and ggi

On Thu, 5 Aug 1999, Andreas Beck wrote:

> > Plus this driver is needed to properly virtualize the accel engine 
> > to each process. 
> 
> Great. They finally bought this ...

Some have. I have support from Geert and Garik, who also is a XFree86
developer as well. In fact Garik is one of the most open minded people for
the kernel developers. They are willing to support my work under two
conditions. One that the accel stuff be handled by a seperate driver
(/dev/gfx). The reason being that not all fb devices don't have a accel
engine. It also wipes their hands of responsible of programming the accel
engine. Two that the performace decrease is very very small. If I can show
that the kernal can handle accels with a less than 10 % perforamce
decrease than from hitting them directly they are will support me. If I
can support then the only people who will really be against me are
Sorsenson and Linus himself. Garik know it will be very tough to get it
pass linus. Alot of kernel developers would have to put the press on him
to accept it. In fact you don't reailize the hard time linus gives the
fbcon developers. He hates fbcon and is very glad very few people use it
on intel platforms. Recently a patch was developed to have a new write.
The current write assumes that the MMIO is the same endianess as the
machine. This is not always the case. So a new write was developed by the 
fbcon guys. They are having a really hard time getting this pacth in. The
only reason fbcon exist is because their was no choice. Some machine only
have cards that don't support any type of text mode.  

> > open say 3 OpenGL programs in X then each window open will open /dev/gfx
> > with that window area. With this driver when you mmap say the Z buffer for
> > window one than only the area of the window is mmapped. 
> 
> This is hard on most platforms, as paging granularity is in the way. But
> better than nothing. A real good solution is only possible with hardware
> designed for that.

Yep. You have to cheat a little bit. Not a perfect solution. Of course
this is down the road. Also their is the problem of window overlap. SGI
have a special byte (maybe word) that holds the window id in the
framebuffer. 

> > Most noteably how to handle the accels registers. They are
> > the tricky part. Any ideas here?
> 
> I can offer advice here. Basically there are two possible solutions:
> 
> 1. Direct mapping and a save/restore mechanism for context switching.
> 
> 2. Streamed access using something like the PingPong buffers discussed here
> again recently. This design helps, if 1. is not feasible, as e.g. the card
> state cannot be completely restored/saved.

Very similar to SGI except in SGI /dev/gfx is a actually stream device.
You keep feeding it accel commands and it process them one after another.
With ping pong you batch the commands?  Ping pong seems the way to go.

> More in PM. Just ask. I have put much thought into that in the past.

No problem. I'm almost done with the the fbcon patch so my next project is
the creation of /dev/gfx.  Even more important than the console redsign.
Mares can attempt that until I'm done with /dev/gfx then I will give him
hell. he he !