[WARNING, this is a long response that addresses the pros and cons of
separating the 3D drivers from XFree86]
David Johnson wrote:
> If anything I would like to become even less dependent on
> XFree. I think one of the things that scares potnetial developers away is
> the fact that they have to download megabytes and megabytes of XFree code
> and then they have to wade through all that to figure out where they can fix
> a driver bug. If the only thing people had to do to hack around with
> drivers was download 150K of driver code and some standard XFree and DRI
> headers, compile it and drop in their XFree driver directory I can guarantee
> you there would be more developers here. XFree is a big ugly beast that is
> intimidating to potential new developers. It isn't like the kernel where
> there is a drivers, drivers/net, drivers/usb, etc. directory structure. In
> fact, you don't even need to download kernel source to build a kernel module
> either. We should make it simpler, not more complex. DRI obviously has to
> have ties to XFree but more at a design/integration/API level not
> necessarily as a shared code base.
Hi David,
I realize you posted this almost a week ago--so I apologize for
responding so late...however, it's something I think is worth addressing
and I'm just now getting a chance.
I agree that we should make every effort to make our build environment
developer friendly. You raise some good points about possibly
separating pieces of the build. First, I'd like to clarify a couple of
points in favor of separation; then, point out some potential pitfalls;
finally, I'd like to open this discussion up to feedback from other
developers.
The areas I believe are "natural" points of separation are the kernel,
2D and 3D drivers. We already have a fair amount of separation today
between XFree86 and the DRM kernel modules. It doesn't take long for
new DRM developers to quickly realize that keeping up with the kernel
releases and asynchronously following the XFree86 releases is quite a
juggling act. We keep DRM sources in the XFree86 tree AND the Linux
Kernel tree. Usually, the XFree86 tree is used as the main repository,
and the drivers are migrated to the Linux Kernel tree as they
stabilize. It's also important to note that stand alone kernel modules
can be built within the XFree86 tree, if needed.
Another interesting division, though less obvious, is between the 3D
component and XFree86. I believe you referred to the 3D component as
the "DRI"--but I'd like to spin it as the 3D or Mesa component and
recognize that all 3 major components (DRM, DDX and Mesa) all have DRI
pieces; and that DRI is really the underlying framework that allows all
of these to work together. Anyway, Mesa has it's own repository where
new OpenGL API changes are worked out with the standalone Mesa software
renderer, first. When this stabilizes it's migrated to XFree86.
Usually this is a two stage process--going to the DRI repository first
where driver support for the new Mesa changes is worked out, then onto
the main XFree86 repository when it's ready for integration into the
next XFree86 release. It's interesting to note that there is currently
no way to build a Mesa XFree86 HW driver in the standalone Mesa tree. I
have to confess, I was a strong proponent of pushing this support into
the XFree86 tree; and I believe it has saved us some headaches--I'll
details the pitfalls below. However, as I've spent more time
considering a unified 3D driver architecture that is portable across OS
platforms--I've come to the conclusion that the unified 3D driver may be
better off coming from a single Mesa repository that is separate from
XFree86. I believe the Utah-GLX project took a similar approach and it
this might have been a reason why it has been reported as "easier" for
new developers to work with.
Providing an easy standalone 3D HW driver does have it's down sides.
One of them is that any new device needs a compliment of graphics
drivers before 3D will work. A 2D DDX driver and a DRM kernel module
need to be written and a device specific strategy for how the hardware
state will be managed needs to be determined down to the register
level. This is a huge task for a single developer, and any developer
that is capable of taking this on, will appreciate having ALL the
components in a single source tree. However, it's not unusual for a
team of developers to work closely to provide this driver suite--and
although the HW state management issues has to be coordinated carefully;
it could be nice for the developers working with a single component to
only need a smaller, component specific tree. Also, it's not unusual
for the 3D driver component to require a significantly larger amount of
work. So the 3D piece takes longer, or theres more developers
involved. Just having a Mesa tree for that work would be good--once the
supporting 2D and kernel components are stable. I can even envision a
unified 3D driver that is being extended and optimized, well after the
supporting components have been done for multiple OS platforms. This
would result in more bang for the buck when a 3D driver is optimized.
The trade off is breaking platforms the developer isn't testing with;
but I think our open development model can offset this somewhat--where
somebody else usually finds the problems on other OS's relatively
quickly.
Another pitfall that comes to mind is we're going to have to deal with a
significantly larger number of incompatability problems if we separate
the trees. Right now, we get a lot of compatability for free by forcing
everything into one release tree. We should consider pushing EVERYTHING
back to XFree86 for actual release (on *nix anyway). As this will
create one less dependency for a Linux integrator--which many times ends
up in the user's face.
I think the level of reorganization involved with separating out 2D and
3D trees will be a MAJOR disruption to current development. We should
consider waiting until we have a major structural change that's going to
impose a similar level of disruption, like a Unified Driver Interface
and if we have a solid plan that minimizes the pitfalls, possibly
address the seperation at that time.
I'm interested in hearing additional comments--especially first hand
experience with separate 2D and 3D trees for graphics development.
Regards,
Jens
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
