[Mesa-dev] KWin and Mesa

[Jerome Glisse]

On Wed, Apr 20, 2011 at 8:01 AM, Martin Gräßlin <mgraesslin at kde.org> wrote:
> On Wed, 20 Apr 2011 04:32:25 +0200, Henri Verbeet <hverbeet at gmail.com>
> wrote:
>>
>> On 19 April 2011 16:52, Martin Gräßlin <mgraesslin at kde.org> wrote:
>>>
>>> Hi Mesa-devs,
>>>
>>> yesterday I published a rant about Mesa breaking KWin and given some
>>> comments on Phoronix Forums it seems like there is the wish for more
>>> communication between our development groups and so I want to start it.
>>> Please
>>> note that I am not subscribed to this mailing list, so please keep me in
>>> CC (I
>>> might not be able to reply this week at all). It is my wish to never have
>>> to
>>> rant about the state of Linux drivers any more and that I never have to
>>> see
>>> Mesa breaking KWin again.
>>>
>>
>> I think there are a couple of points here, some of them already made
>> by others. Note that the following is mostly just how I personally see
>> things, not necessarily what anyone else thinks.
>
> Thanks for your mail. This is really constructive and a reply in the kind of
> I hoped to receive. A good starting point to fix the mess we are currently
> in :-)
>>
>> First, there's the specific issue your blog post talks about. While I
>> understand the issue, and can sympathize somewhat, I essentially think
>> you're just wrong there. (Yeah, I can be direct too.) It's perhaps
>> unfortunate that this change happened on a minor release, but the
>> basic issues are that blacklisting / whitelisting drivers is just a
>> bad idea, and you can't depend on renderer strings being stable. If
>> you do it anyway, it's going to break, you get to keep all the pieces,
>> and you can't blame the drivers.
>
> Actually I agree with you and all other who wrote it: it is a hack and it
> should not be there. It was added to make KWin at least "work" around the
> 4.5 release. As a matter of fact and that question might sound stupid, where
> do I find information on additional API provided by Mesa than not parsing
> the renderer/version string? In the response to the blog post I received
> replies that we should use DRI2QueryVersion. That was the first time that I
> heard this thing existed. Where is that documented? How can we find out
> about it? I seriously have never ever heard about it or read about it in any
> documentation I have read so far.
>>
>> In the more general case, I think hacking around driver bugs is about
>> the worst way to deal with driver bugs in GL applications. In the best
>> case you're just removing an incentive to fix the bug, but it's more
>> likely you just end up creating fragile code or depending on the bug
>> somehow.
>
> The problem is that at the time we release it has to work. Our users do not
> care about whether it is the driver or not. It just has to work. A big
> problem in that regard is as you noticed yourself the distributions. They do
> not ship updates to the drivers, so we need to make it work with the driver
> version out there and not with the next bug fix release. Our work would be
> much easier if we could just tell the users to update their drivers ;-)

Your issue is right there, gnome-shell have been successful dealing
with that because they target a particular mesa version and they set a
lower bar for the GL feature they need. Your issue is that you want to
enable feature that are using too advanced GL stuff for the opensource
driver, GLSL wasn't that good before mesa 7.7 (or even 7.8 can't
remember). What you should do is decide was is the lowest mesa version
you are ready to support and then use that to decide what gl feature
you can safely use. If you want to support debian that would more than
likely mean dropping glsl. Trying to enable feature one by one is a
real bad idea, again i believe here gnome-shell took the right
approach.

Cheers,
Jerome