[Mesa-dev] Mesa/Gallium overall design

[Dave Airlie]

2010/4/13 Michel Dänzer <michel at daenzer.net>:
> On Mon, 2010-04-12 at 10:12 -0700, Jesse Barnes wrote:
>> On Mon, 12 Apr 2010 09:00:57 +0200
>> Michel Dänzer <michel at daenzer.net> wrote:
>>
>> > On Mon, 2010-04-12 at 08:00 +0200, Luca Barbieri wrote:
>> > > The Intel drivers also appear to be in the same situation, with
>> > > classic drivers not being dropped in favor of Gallium ones, also
>> > > indicating possible Gallium shortcomings leading to this.
>> >
>> > The reasons for that are mostly political rather than technical.
>>
>> Sorry, couldn't resist this flamebait.
>>
>> My message wrt Gallium has been consistent at least, and I know the
>> other Intel developers agree with me (though they may have additional
>> issues with some of the interfaces specifically).
>>
>> Moving to Gallium would be a huge effort for us.  We've invested a lot
>> into the current drivers, stabilizing them, adding features, and
>> generally supporting them.  If we moved to Gallium, much of that effort
>> would be thrown away as with any large rewrite, leaving users in a
>> situation where the driver that worked was unsupported and the one that
>> was supported didn't work very well (at least for quite some time).
>
> This may be true now, but only because you guys refused to pick up
> Gallium early on. That's what I was referring to, the technical reasons
> above are merely consequences of that decision IMHO.

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

> If you had picked it up, the resulting drivers could be expected to be
> at least as stable and performant, but definitely provide more features
> (e.g. OpenVG support) now. Gallium as a whole would probably be better
> for it as well.

I think it would have put Intel 6 months behind schedule, and it was
just after bugmgr (I typoed bufmgr but it seemed apt) which was
already a massive upset, along with dri vs dri2.

I'd really have liked if the open i915g and i965g had gotten some
serious time allocated, I think the things that might persuade Intel
the upset is worth it going forward, is gettting a useful gallivm/915g
combo on their 945 based netbooks, (i.e. save power and run
googleearth well), then for 965 I'd expect some sort of GS support
would help, but still the regression chasm is wide and i've no idea
how to span that in a distro release cycle.

>
>
>> I really wish the move to Gallium had been a more gradual evolution of
>> the current code base, since it would have allowed working drivers to
>> take advantage of the new infrastructure over time (though not having
>> worked with Gallium I won't pretend to suggest how this might have
>> worked best).
>
> Indeed, would have been difficult I think given Gallium's goal of a
> radically simplified driver interface.
>

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.

Dave