[Mesa3d-dev] Re: [forum] Notes from a teleconference held 2003-3-27

[Brian Paul]

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