From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Mon, 1 Feb 1999 15:15:19 -0500 (EST)

Re: The battles.

On Mon, 1 Feb 1999, Morten Rolland wrote:

> James Simmons wrote:
> > 
> > I see no reason to do software accels in the
> > kernel when you can do that in userland to avoid the cost of a context
> > switch.
> 
> Wouldn't this be at the expence of sequencing or fragmentation?  If
> you had a program doing:
> 
>   1) Fill-Rectangle   (to paint the background black or something)
>   2) put-some-image   (to draw something)
>   3) Draw-Line(s)     (to make a nice border)
>
Their are two new iocttl calls. One tells you what accels in hardware are
supported and the other sends the batched accel commands. 
 
> If (2) is not available as an (emulated) accel in the kernel, you have
> to
> break up the accel list into two ioctls - with a userland
> "put-some-image"
> performed in the middle?
No call the accel capability ioctl call. If you don't use this and still
call the accels it will just ignore the command. The reason to avoid
software emulation kernel side is to avoid putting things like software Z
buffering into the kernel. This would be bad and very very slow.

> 
> If a card lacks an important and much used accel, this would potentially
> chop the accel-list into a lot of segments... Giving a lot of context-
> switches.
>
Need to use that accel ability call. Then you make sure you don't send
that packet.

> This is all new to me, so I may be way off... Anyway, I enjoyed reading
> the patch a lot.  I think it's made of the right stuff.
> 
> - Morten
> 

No. You made some good points.