[Mesa-dev] Mesa/Gallium overall design

[José Fonseca]

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.

Furthermore, I don't think we still need to prove Gallium to anybody.
The architecture makes sense, and there are plenty of proofs it works
for those who want to see. The odds are if we don't do the porting work
then somebody else will eventually do it when there is an itch to
scratch. And we should focus where it really matters at the present.

> I do also wonder if something more akin to making gallium as a driver
> plugin instead of drivers plugging into it, i.e. a driver tells
> gallium to plug itself into all the mesa dd entrypoints, then can
> override any it wants to do itself. Granted it wouldn't have gotten
> use away from the GL interface. It would have probably looked like the
> meta.c stuff we finally started building up, to make classic less
> painful.

Gallium in its essence is the abstraction between the graphics APIs and
graphics HW. What you propose here sounds more like porting some of its
utility code or part of its implementation and provide it as an
auxiliary to Mesa drivers. But doing that would leave nothing of Gallium
essense.

Combining a Mesa classic driver with the Mesa state tracker sounds
technically feasible initially, but in order to share surfaces and
internal state you'll need to share code, hence the class driver will
have to look pretty much as the Mesa state tracker + a pipe driver
anyway. And all the interations between the classic and gallium code
paths will probably introduce more bugs than those they will prevent.

Jose