Re: The whole GGI/KGI spat

On Thu, 27 Mar 2003, Kendall Bennett wrote:
> The first thing I would say is that I don't believe any of the 
> discussions about GGI and XFree86 have been flames at all.

Good.  I don't either but it looked to me like things were starting
to slide a bit in that direction.  It's comforting to know skins aren't thin
here on this list.

> The XFree86 group are not going to ditch the existing device driver model 
> (and more importantly all their functional drivers) unless there is a 
> compelling reason to do so. Hence a GGI based loadable module fits nicely 
> into this scenario since it can be used to 'extend' the device support 
> for XFree86 rather than trying to replace it.

That would be great.  The only thing is that problem we ran into of XFree86 
being under the impression that all display systems have a bus/irq/device
associated with them.  If that can be resolved, then at least for those
display systems that offer (or emulate) direct access to the framebuffer 
RAM, the implementation should be simple.

(Another thing that would be nice is if code were reviewed to prevent
instances where the base frambuffer address is copied.  Getting everything
to use a master copy of the pointer would make it easier for people trying 
to do x session migration.  I'm not saying there actually are instances 
of this, just if there are...)

> > Also I don't think there are many here that do not realize that in
> > order to milk hardware for what it is worth, X needs much more
> > thorough kernel-space support than currently provided by DRI. 
> 
> That is an interesting comment you make, and one that I don't quite 
> understand. What exactly do you feel needs to be done better in the 
> kernel space in order to be able to 'milk hardware for what it is worth'? 
> I don't see any serious performance issues with the current way that 
> XFree86 works (and the DRI works), but I am curious to hear your ideas 
> about how it can be made better.

Well, I mean mostly that DRI still falls short on the asyncronous handling.
From what I have read of the DRI source (admittedly not too thoroughly)
there is some support for a userspace process to wait on VSync/VBlank,
but no or very limited support yet for keeping track of buffers
kernel-side so arbitrary command streams to perform all the soft-realtime
tasks can be started immediately after an IRQ without waiting for the 
userspace process to be found and reentered by the scheduler.  This 
in turn necessitates a system for interlocking buffers that doesn't
burn away any gain thus realized in performance as the server tries to 
figure out if a buffer can be reused yet or not.  That and prioritized 
queues when multiple apps are banging the hw, but I'm not sure if multi-app 
use is actually even a stated goal of DRI or not.

(Not my only criticisms of DRI, mind you, but the only one I can 
think of right now that applies to what DRI *is* trying to do vs.
what I think a kernel graphics system *should* be trying to do.  For
that, consult KGI mailing list archives as that topic has all been 
hashed out many times there in the past and many good opinions in
addition to my own are in the mix.)

Anyway, back to coding.  Hopefully this time I strategically managed
not to say something that will draw me further in :-)

--
Brian S. Julin
GGI and KGI Projects