[Mesa-dev] Mesa/Gallium overall design

[Keith Whitwell]

I'm much more relaxed about the future of Gallium these days.  I don't
think there's any sense in pushing people or projects towards it -
people are welcome to evaluate it on its merits and make their own
decisions on that basis.

The project itself is clearly on a strong footing.  We've shown we can
correct from poor design choices without disrupting the entire stack,
and keep the interface a dynamic, evolving entity even with so much
built up around it.  And though there's clearly room for improvement
in how we (and I) deal with newcomers, I hope we've demonstrated we
can incorporate new ideas and new voices without letting go of the
fundamental idea of the project.

Though I'm sure it will provoke intense discussion, the next time
someone figures out we've made some fundamental miscalculation in the
design of gallium, and have the patience to convince us of it, I have
no doubt that it will be possible to resolve the issue and carry on
stronger.

As far as this thread goes, I think it's probably fine that there's
some chance to put voice to past anxieties & remember old
disagreements, but there's fundamentally too much good work to be done
in this space to spend a lot of time worrying about that stuff.

Keith

On Tue, Apr 13, 2010 at 8:16 PM, Bridgman, John <John.Bridgman at amd.com> wrote:
>>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".
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>