[Mesa-dev] Mesa/Gallium overall design

[Bridgman, John]

>No, it was true even as the first Gallium code was landing in the
>repo.  Rewriting everything is always painful, and we already had
>plenty of other tasks to keep us busy (see Dave's mail) and cause pain
>for everyone.  In hindsight, maybe it wouldn't have been any worse than
>what we went through, but since the 3D driver is the biggest part of
>the stack, throwing away that part seemed like it would be the biggest
>amount of work.

>Dave's other points are also good ones; Gallium has yet to be proven
>with a big, open source, shipping, and supported driver.  I won't
>comment on the closed source stuff; I've heard things but haven't
>actually worked on it myself, so I have no idea whether there were good
>closed source drivers released or not.

We made essentially the same decision as you 18 months ago and implemented the initial r6xx/r7xx 3D driver on the "classic" HW driver model rather than Gallium3D. Even at the time it seemed highly likely that Gallium3D was going to work out well, but between the newness of Gallium3D itself and the work still to be done on KMS/DRI2/GEM/TTM there was just too much "new" for my liking. 

We did ask one of our devs (Cooper) to help with the Gallium3D effort and also look into video decode using G3D, but unfortunately he got pulled off onto another urgent non-driver project shortly afterwards so we didn't end up doing much to help at all. Fortunately the other developers pushed ahead without us (thanks guys ;)) and it's probably fair to say that our developer focus will probably jump across to r600 on Gallium3D fairly soon as well.  

For what it's worth, if we were writing a new "has to work, can't afford delays" driver from scratch today we would go with Gallium3D, period. Prior to that... I think we were confident it would all work but weren't quite sure how long it would take. 

The reality is that we don't have a conveniently timed architectural break to force the writing of an all new driver, and I imagine you don't either, so we're all going to have to "ooze" across to Gallium3D. The initial code to support Evergreen (HD5xxx) GPUs is being implemented on top of the "classic" r600 driver because so much of the programming model is common, but from that point on I think we would try to push the Gallium3D code ahead rather than doing more work on the classic code base.

I'll try to get a statement from our proprietary OpenGL driver team re: compatibility profiles -- or, more to the point, deprecating older GL functionality. I haven't looked into the issue much myself but my first impression was definitely "uh-oh, this is going to be a problem for a bunch of our users".