On Wed, 20 Apr 2011 04:32:25 +0200, Henri Verbeet <hverb...@gmail.com>
wrote:
On 19 April 2011 16:52, Martin Gräßlin <mgraess...@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 ;-)
IMHO it's better to just direct users to the appropriate bug
tracker in those cases. You'll get some flak for that, but it's worth
it in the long term. Of course the best way would be to work on
fixing
the bug in the upstream project, but I realize that may not always be
practical.
We do tell the users to report the bugs upstream. I don't know if they
do it, but we tell them. We cannot do much more - I personally don't
want to play proxy for bugs I cannot reproduce with my hardware. I also
reported the only bug I ever encountered with free drivers,
unfortunately nobody ever replied to it.
Note that I think distributions have some role to play here as well.
I
think it's just about as unreasonable to expect driver developers to
test with every application as it would be to expect KWin developers
to test with every possible hardware / driver combination. (And you
can't say "My application is more important." either. You're going to
find plenty of users that would gladly have us e.g. completely break
KWin to make StarCraft 2 run faster, and viceversa.) Realistically
speaking we'll have to depend on users / testers testing with
development versions to find bugs before releases. If nobody reports
bugs that either means nobody noticed or nobody cares. An important
part of what distributions are supposed to do is making sure things
work well together, so I don't think it's all that unreasonable to
expect them to do that kind of testing and report / fix bugs where
appropriate. If it does come to the point of writing hacks (pending a
proper fix) it's probably also more appropriate for a distribution to
carry those than KWin.
Normally distributions do not want to have specific code. Especially
KDE discourages distros to create specific hacks. If I think of Kubuntu
they for example would not have the manpower to create the patches and
would ask me to fix it. Most packagers do not have any knowledge in this
area. But it's also working now: Ubuntu includes a fix for the problem
now (adding "GEM" again) and Fedora is at least interested in adjusting
the code to make it work with Mesa 7.11 (which I will not consider for
our next point release, but only for our next major release).
Something else. Blogging is all modern and all, but it's really not
the most constructive way to make things actually happen. In fact, I
could certainly imagine this specific blog post causing some
resentment. In general, for specific bugs / regressions, please just
create a bug report, preferably with a small test case or even a
proposed patch. For more general issues posting to the mailing list
or
just talking to people in IRC (#dri-devel) tends to work best. If you
really consider Mesa your most important upstream, it's probably a
good idea to be on the mailing list and IRC anyway, just to be aware
of what's going on, even if you end up not reading most of it.
I hope I could explain in my last mail that this time I just did not
have the possibility to discuss with you on IRC or send you a mail in
before. Writing blogs for communication is a typical KDE thing, so yeah
I'm sorry if it causes resentments and because of that I wrote the
lengthy mail to get out of the stupid "they broke us"/"they are doing it
wrong" circle which does not help anybody. I will try to no longer post
such blog posts in future and I hope the mesa devs could stop writing
mess on the Phoronix forums ;-)
Some more random remarks below:
mind. Given how important KWin is for you as a downstream I am
really
surprised to see that you do not do regression tests against KWin.
What can we
do to help you there?
Making sure the functionality required by KWin is covered by piglit
would probably go a long way. If KWin has its own set of automated
regression tests that's likely very helpful as well, though likely
more so for distributions than for Mesa directly. Mesa (like everyone
else?) doesn't exactly have huge amounts of developers / QA staff
waiting for something to do, so to make something happen there you'll
probably either have to automate it or find some people who care
specifically about KWin on Mesa and have them test it on a regular
basis.
I am working on getting the compositor to compile without the window
manager to be able to run it as standalone application and as the base
for some test suites. This will take some more time - we will most
likely get a GSoC project which will implement parts of it. Concerning
piglit: I think there are more experienced people than me to actually
write the tests. One of the problem for me is that I do not speak
Python. I hope that when we have the compositor standalone we can just
add a few piglit tests on top of it and test everything what KWin
provides. But as said: it takes some more time.
Anyway even if I were able to follow the upstream development it
would not
help much. The combinations of hardware, driver, mesa, kernel and
distribution
are way too high that our team can ensure that it does not break.
This is
I don't doubt development manpower is limited, but don't you have any
users / testers interested in testing development releases either?
Too limited to actually be able to test everything or not knowledged
enough to really understand what they need to test :-(
Cheers
Martin
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
