[Mesa-dev] Mesa/Gallium overall design

[Alex Deucher]

On Tue, Apr 13, 2010 at 6:01 AM, José Fonseca <jfonseca at vmware.com> wrote:
> On Tue, 2010-04-13 at 00:55 -0700, Dave Airlie wrote:
>> No offence to gallium, but I don't think its been mature enough to
>> ship a driver for as long as Intel have had to ship drivers. I'm not
>> even sure its mature enough to ship a driver with yet. I know you guys
>> have shipped drivers using it, but I don't count the closed drivers
>> since I haven't heard any good news about them, and svga is kinda a
>> niche case.
>
> First, I don't core about who jumps into the Gallium ship or ignore us.
> Certainly the more the merrier, but Gallium is a worthwhile proposition
> even if the whole world decides to ignore us.
>
> But I can't let this "gallium is not mature" excuse go unchallenged.
>
> When you say "I'm not sure it [Gallium] is mature enough to ship a
> driver with yet", what components exactly are you referring to?
>
> A Gallium GL driver is composed of:
> - Mesa. The very same same used on classic drivers. So I suppose you
> don't refer to it.
> - Mesa state tracker. Quite small. A lot of is quite similar to Mesa
> meta.c stuff.
> - Gallium interface. Always in flux, granted, but what exactly is it
> missing to ship stable driver?
> - Auxiliary modules. All optional.
> - The pipe driver -- this is *not* Gallium -- just like as a Mesa driver
> is not Mesa.　And is as stable as people make it.
>
> All things considered, it is way less effort to write and maintain a GL
> Gallium driver than a Mesa driver. So if there isn't a stable Gallium
> driver for hardware X, Y or Z it is simply because nobody put their back
> into making it happen.
>
> Also, the closed drivers that you decided not to count were as stable as
> they could be in the allocated time. When we were stabilizing the
> Windows GL SVGA driver we fixed loads of *Mesa* bugs, because all the
> windows-only applications we tested with that were never tested before.
> Actually looking back, most of the bugs we had were in the pipe driver
> and Mesa. That is, relatively few were in the components that make the
> Gallium infrastructure.
>
> Migrating into Gallium is a time investment. One puts time into it, and
> then it expects it pays off: either because of the increased code
> sharing, more API support, or the optimizations it has which are only
> possible because they extend beyond a single driver. There are several
> reasons, but they might not appeal to all.
>
> I can concede that migrating may not have been perceived as an
> worthwhile investment by Intel two years ago, today, or in the
> foreseeable future. It is for Intel maintainers to decide whether the
> pluses are more than the minus.
>
> But please stop trying to find excuses in Gallium for why driver A/B/C
> has not migrated.
>
>> I've made the point to Keith and TG a long time ago that
>> we needed an open source show case gallium driver to show how one
>> should actually look. Either Intel 965 or ATI r600 would have been
>> perfect targets. This never materialised as important enough. So I
>> don't think you can blame Intel, the argument for switching to gallium
>> 2 years ago wasn't pervasive at all. Its only coming to be pervasive
>> now, and my only real interest stems from llvm'ed vertex shaders as a
>> killer features on non-TCL hw, and for doing some tcl fallbacks fast.
>
> Trying to port drivers to gallium without the de facto maintainers
> cooperation is effectively a fork, and if we don't have resources to
> sustain the fork then it is bound to die.
>

I'm sure developers would be interested in cooperating;  AMD certainly
would be.  We would have preferred to do the original r600 3D driver
on gallium, but at the time we needed to support UMS and the legacy
drm.   KMS and memory manager support were not even implemented for
r6xx+ class hardware at that time.  I realize a good memory manager is
not a hard requirement, but it would have been pretty painful.

Alex