[Mesa-dev] Mesa/Gallium overall design

[Dave Airlie]

On Tue, Apr 13, 2010 at 8:01 PM, 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.

No open shipping driver on real hardware in any Linux distro == not
mature in my opinion. The interfaces remain unproven on real hw
platforms, the fact the nouveau people are raising issues as we get
closer to shipping stuff is a sign of it. I'll retract the yet
statement I'm still happy with where Gallium is right now, its
probably mature enough now after the last bunches of merges, but long
term we'll see how the interface stand up and regressions come and go.
.
> - Gallium interface. Always in flux, granted, but what exactly is it
> missing to ship stable driver?

Pretty much this. The interface is still under such heavy development,
that I can't say I could have released r300g and QAed in the zones of
stability in master. Yes I could have stuck to the Mesa 7.8 version of
gallium
but then I'd just have to start the process again for 7.9. The thing
is you aren't developing one-off snapshots for contract anymore, we
need something that is sustainable and regression testing friendly so
that we can produce rolling working drivers every 3-6 months with a
minimum of regressions. I think we have gotten a lot closer to this,
but we'll see as we start to actually ship gallium drivers in Linux
distros.

> - 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.

For any hardware at all? you really don't see a problem with that?

>
> 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.

As I said SVGA doesn't count its not real hw, it relies on much more
stable host drivers yes, and is a great test platform for running DX
conformance, but you cannot use it as a parallel to real hardware. The
closed drivers were paid for embedded one-offs, no sustained
developement dead ends. So again I can't count them.

>
> 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.

No driver has migrated as of yet. Lots of us are investing in
migrating drivers and can see the upside, however I can also see why
Intel remain reticent.

>
> 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 still think a real driver is more important than anything else, you
can't showcase something without one. You think Gallium sells itself,
it would have if a real optimised open driver had existed from close
to the start. Its a pity the opportunity was lost, but at this point
maybe enough people are scratching itches. A 915 or 965 driver that
produces similiar speed as the classic driver would have made it a lot
easier for people to see.

>
>> 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.

Yeah this was more a if we had time 2-3 years ago to take a different
path that didn't care about DX* or other stuff, I'm not saying we
should consider it now. It was just an idea to try making mesa classic
drivers less painful.

So don't feel like I'm attacking Gallium here, I'm just trying to
state its a new technology and I'm very happy developing r300g with
it, but its far from a proven replacement for classic mesa.

Dave.