On Thu, Jan 24, 2002 at 08:07:18PM -0700, Jens Owen wrote: > [WARNING, this is a long response that addresses the pros and cons of > separating the 3D drivers from XFree86] > ....
I'd like to respond to just a few things in Jens's excellently written email. > 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. ... Not if things are designed properly. see below. > 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. If you make stipulations like that, it will NEVER happen. [or, contrariwise, it's time to make that Unified Driver Interface!] If you agree that it's a good idea, and that it should happen.... it should happen as soon as someone capable is wiling to do the work on it. Now, to address what "it" might look like: I think having the driver stuff buried way under the DRI source, which itself is buried deep in the xfree source... is *nasty*. One of the best cleanups possible, IMO, would be a one-two punch in the driver arena: 1. Minimize the driver interface, to make it both easy to port, yet flexible to allow lots of future possbilities. WIth the right driver interface, there would be minimal future incompatibility problems, because the driver interface would not have to change. See lower down for details on a potential interface. 2. Strip it out of the tree completely. Document in the DRI subtree, "This is the API we need: .... These are the drivers known to implement it, on these OS's" For example, instead of a whole bunch of different odd hardware-specific calls, limit the driver to the following classes of operations: 1. AGP (and make it SIMPLE!) 2. DMA (See above) 3. write register/read register [*] This should cover EVERYTHING possibly needed. [*] The "write register/read register" should be made to use PCI register sets, instead of any hardcoded addresses. So instead of "write a byte to I/O address 0xc0f", you would make a call to "write a byte to register set 1, offset 0x2". This gives lots of benefits, from being intrinsically "cleaner", to meaning that you no longer have to be doing driver-type operations directly in user-space. Well, you kind of are, but at least it's a LITTLE more abstracted. I think the reliability factor here is worth the slight degredation in performance that this would entail. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
