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

Re: The battles.

> Yeah, but it's difficult. So I've been telling Cyrix that KGI makes sense. On
> 
> the other hand, X is what's shipping, as is Mesa. But then you have to
> support
> 3 things (X/svgalib/Mesa) for like 7 million users of which how many will buy
> 
> your card? So either you outsource it, or you don't bother, or you let your
> engineers
> do it at home... It's a "who has the momentum thing". Managers look at that.
>

Thats what I'm trying to point out to people. Many companies will NOT
outsource it and linux is in no position to strongarm them to release
specs.
 
> > The patch is at http://www.stud.enst.fr/~bellard/
> 
> Looked at the documentation -- not the patch, it's enourmous.
> Seems ok to me. 3.3 times slower is bad though, although your test
> implementation looks really naive. I'd just add the option to queue x ioctl 
> display buffer addresses in the kernel to ensure ioctl's don't block.
> 

That was the worst case with drawing a single point. Plus this was with
software emulation too. The patch has been rewritten. In the old patch
to test userland accel I had the software emulated accels available in
userland. In the new patch I plan to have only true hardware accels ported
to userland. The software emulationed accels will NOT be available from
userland in the new patch. 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.