[Mesa-dev] Mesa/Gallium overall design

[José Fonseca]

On Tue, 2010-04-13 at 03:52 -0700, Dave Airlie wrote:
> 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.

OK. I admit the interface churn doesn't quite fit into the 3-6 months
release cycle.

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

No, I really don't. I see the current state as an historical
consequence, in particular of the projects we happened to work on, and
not a shortcoming in the Gallium architecture itself.

If we had officially worked on migrating a driver for a particular
hardware, or writing one from scratch, and not been able to succeed then
I would accept your critics. 

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

That just adds to my point: even on pseudo hardware as SVGA, I found
many bugs in Mesa proper, in code shared with all the classic Mesa
drivers that you say are stable. The bugs were in no way SVGA related.
They were simply due to the fact many Windows GL apps push the limits
way beyond the apps available in Linux. 

Which is why I think this "mature" reasoning is all moot when talking
about graphics drivers. At the end of the day what matters is what QA'ed
and tested: even a supposedly mature component such as Mesa evidences
many bugs when tested with new apps; and the reverse: with enough QA,
testing and debugging even a supposedly immature component can become
stable rather quickly.

And this is why I state that the fact there are no stable open source
hardware drivers is a consequence of such effort has never been scoped
so far, instead of being a property of Gallium.

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

Basically I feel you're measuring the work we did and released (the
architecture, the infrastructure) not by its own merits, but based on
tangential stuff that was not done (open source hardware drivers).

Anyway, you and everybody are free to make their own mind. I can
understand why you ended up with this opinion. I do not agree and I was
trying to put it into my perspective, but I think I did too much of that
already.

Jose