Jens Owen wrote:
Michel,

You're bring in issues that effect more than just the X development community here, so I'm copying the DRI and Mesa developers.

Michel Dänzer wrote:

On Don, 2003-04-03 at 22:03, Alan Cox wrote:

From the DRI people's point of view, it leads to more work as we'd want our drivers to work with both trees -- but that's pretty much life, and we'll have to do what we can to minimize the effects on us.


Perhaps a test of Keith's theory is that DRI should be able to be -part-
of not just working with his tree.



I think we should first discuss (more) the pros and cons of folding the
DRI tree into other trees. I do find the potential benefits (for merges
in particular) compelling, but there's e.g. the danger of making it harder
to get it integrated with other components like e.g. DirectFB or other OpenGL implementations.




Folding the X specific work into an X project makes alot of sense from a technical perspective. My biggest concern would be losing developer momentum by removing this work from a developer friendly project like the DRI.


The Mesa specific parts and the supporting kernel driver parts could be pushed into the Mesa tree (this has already been done for the embedded branch). Currently, the Mesa project is very focused on the API and the full software stack that supports that API in a wide range of windowing environments while the DRI project is focused on hardware acceleration in the X environment. It's technically feasible to transition the development of the Mesa hardware drivers (currently done in DRI) to the Mesa project. However, we still need to worry about developer momentum as two focuses would now be in the Mesa project (API and 3D HW).

That could be a good thing.


First, as it is now, Mesa development is a little like duck hunting - aiming ahead of the target. That is, I try to implement extensions in anticipation of upcoming hardware features (texture cube maps, texture combine, texture rectangle, shadow maps, vertex/fragment programming, etc). It's often months after I finish an extension in s/w Mesa that we look at hardware implementations.

Sometimes I find that I have to go back and re-do parts of the software implementation to make it work for hardware.

If the hardware drivers were in the Mesa tree, the hardware implementation of new features could be done more efficiently and sooner.


Secondly, during DRI IRC a few weeks ago we made a point that should probably be repeated: the interface between core Mesa and the h/w drivers is _much_ more intricate than the interface between the h/w drivers and XFree86.


Yet the former interface is where we've actually split the code bases!

The embedded Radeon driver project has demontrated that the driver's ties to X aren't too strong and that that dependency can be abstracted away. The interface between the h/w drivers and XFree86/DRI hasn't changed in a long time; it's pretty static.

Ideally, if the 3D hardware driver were developed within the Mesa tree, the complexity barriers which discourage newbies could be lowered a bit - someone could download the Mesa tree, do some coding, compile and immediately try out drivers without having to build a whole X tree.

The 3D drivers could also be used outside of X, like the embedded/fbdev Radeon driver.


I think the following block diagram illustrates the key areas of 3D development focus, and the transition that's being suggested:


Now: Mesa Tree -----> DRI Tree -----> XFree86 Tree - API Focus - 3D HW Focus - Complete Window System Focus - X/3D Integration

Possible
Future:  Mesa Tree -----+--> XFree86 Tree
         - API Focus    |    - X/3D Integration
         - 3D HW Focus  |    - Complete Window System Focus
                        |
                        +--> Alternate X Tree
                        |    - Duplicate X/3D Integration
                        |    - Possibly more 3D developer
                        |      friendly, who knows?
                        |
                        +--> FBDev Subset
                        |    - FBDev/3D Integration
                        |    - Embedded Focus
                        |
                        +--> DirectFB
                        |    - DFB/3D Integration
                        V
             Other Window Systems:
             DirectFB, WGL, AGL and
             new ones that haven't
             been invented, yet.


I would like to hear the concerns from the developers that support the API, 3D HW and X/3D Integration before considering any kind of transition. IMHO, supporting the community of open source developers that make 3D happen is much more important than control over any one project.


In anticipation of Phil Brown's likely response I'll say "No, doing this would not compromise the platform-neutral nature of core Mesa." :)

-Brian



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to