Phil,
Thanks for your response. I think you bring up some good points related
to a UNIFIED DRIVER interface--so not to confuse our audience I've
renamed this thread.
Philip Brown wrote:
>
> On Thu, Jan 24, 2002 at 08:07:18PM -0700, Jens Owen wrote:
> > 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!]
>From a technical development perspective, we can certainly address a UDI
now--however, 3D driver work is resource intensive. There are more full
time 3D developers on one of the proprietary IHV development teams than
there are in the entire DRI development community. We never let that
deter us in the past--but we were always cautions about how we
approached large scale changes. The current DRI infrastructure and
drivers has OVER 15 full time engineering years in it; and that's a lot
for a our small team of experts (but a drop in the bucket for ATI, Intel
or NVidia). Consequently, we approached projects in a fairly
"Cathedral" style. However, things can change and evolve--and NEW OSS
community members are key to making progress. A "Bazaar" style
development would be great to see.
> 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.
If you're still talking about a UDI, it's going to take a large effort
just to prototype these changes on a seperate branch with just one
driver. A "Bazaar" approach here would be great, if we had the man
power, and could reasonably throw out 90% of the implementations. Who
knows; may we'll gut lucky and some unknown developers will come along a
release a mega-patch for the perfect UDI. In the mean time, I plan on
slowly pushing that direction by coming up with a design, getting
feedback from all the DRI experts, driver maintainers and IHV's. Then
proceeding with a prototype. This is a much longer process, but I think
it has a much higher chance of being accepted into the future DRI
framework.
> 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.
Which driver interface are you talking about. A unified 3D driver
interface would be almost identical to the OpenGL API. Ideally, we
could abstract out the window system bindings and OS specific resource
management.
> 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"
I'm still lost...you're talking about the Mesa tree, right? Part of my
confusion is the over use of the term DRI.
> 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 [*]
Now you're talking about a lower level interface than OpenGL--but this
could be an important distinction for the "OS Specific Resource
Management" I eluded to above.
> This should cover EVERYTHING possibly needed.
This approach could work for one or two styles of hardware--but there a
more variations and need out there. I'd like to see a design that was
flexible enough for many styles, even if the initial implementation only
supported a single style.
> [*] 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".
A small amount of 2D init functionality still uses programmed I/O (in
and out instruction on x86), everything else have moved to a relocatable
base address for memory mapped I/O (mov instruction on x86).
> 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.
I'm sorry--you've lost me. Can you give an example.
> 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.
Regards,
Jens
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
