Re: radeon-pre-2

[Eric Anholt <eta@lclark.edu>]

On Sat, 2004-09-11 at 14:37, Jon Smirl wrote: 
> On Sat, 11 Sep 2004 22:06:14 +0100, Christoph Hellwig <hch@infradead.org> wrote:
> > On Sat, Sep 11, 2004 at 05:02:36PM -0400, Jon Smirl wrote:
> > > Alan, if you will commit Redhat to implementing all of the features
> > > referenced in this message:
> > 
> > You definitly start sounding like Hans ;-)
> 
> Getting the Linux display subsystem to a point where it can compete
> with Longhorn/Mac is a very complicated problem. It is going to take
> several years of work and the cooperation of a lot of people. It's a
> pyramid problem with lot's of layers.
> 
> Of course Linux can choose not to build a display system based on 3D
> hardware. But I've seen the
> current Longhorn/Mac implementations and they are way, way better than
> X. If Linux ignores 3D mode it is going to be very visible on the
> desktop.
> 
> I've tried to follow the Linux model for proposing the changes. The
> plan has been circulated to all relevant lists: fbdev, dri, xorg, lkml
> for over six months. Three sessions at OLS talked about various parts
> of the plan. Nothing has been kept secret, there must be 5,000
> messages in the archive on this subject.
> 
> But since I've written most of the code so far I get to pick the
> details of the implementation. If Alan would instead like to pick the
> details I've offered to withdraw if he'll write the code needed to
> implement the major points of the plan. Of course if Redhat wants to
> send me a check for a couple of hundred thousand dollars I'll write
> whatever they want, but they haven't done that.

I don't see what longhorn and quartz have to do with the question at
hand (this plan to cram FB and DRM together).

If we want to do the pretty graphics things that these improvements to
graphics on other OSes have done, we don't need to touch FB at all.  We
already have X Servers with the composite extension.  We've got a vector
graphics library.  Now we need to make those go fast.  We can do the
go-faster part within the X Server and the vector graphics library
without touching the DRM, FB, or anyone else.  I'm spending far too much
of my free time currently working on this.

Now, another good project is to get our 3d drivers to the point that we
could write our X Server on top of that.  Basically, we need pbuffer
support for that.  That'll touch the DRM and client drivers (and our
current X Servers, though that part wouldn't be used in the X-on-GL
model).  Again, not FB.

A completely separate issue is how to arrange for synchronization
between the multiple users of the graphics hardware on linux.  I think a
pretty decent model has been proposed by the Linux kernel people, and it
seems rather simple.  FreeBSD is happy with it because it doesn't affect
us in any way.  (When we get around to dealing with the issue (if ever),
i.e. when we've got accelerated graphics layers for console, I'm quite
sure we'll follow the same model of a relatively generic lock in the
kernel which all graphics clients will use to arbitrate hardware
access).

Please, stop trotting out Longhorn and Quartz to justify whatever you're
trying to push into the kernel.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org