Intel Mesa Gives Problems With KDE's KWin, Again

[pingufunkybeat]

You gotta love the sense of entitlement within the KDE community.

The sole purpose of upstream is to cater to KDE and its Kitsch Window Manager. Every upstream commit, even if it consists only of white space fixes, must be tested to make sure it does not negatively affect KDE/KWin in any way. Those who do not abide or simply forget will have to face the wrath of angry KDE bloggers and KDE foot soldiers spewing their hate on various forums.

Reality check: In spite of what you may think, the world does not revolve around KDE. No really.

This is a problem and dates to the early days and Qt license, and grudges from 10 years ago and FSF and Debian's holy crusade to kill KDE. This STILL hasn't been achieved, despite stunts like Eazel, Ximian, and who knows how many corporate millions invested in basically recreating already existing KDE technology because of the NIH disease.

Now there's been such a huge investment into the competing desktop that several major distros do no want to make the logical switch to the desktop environment which is several years ahead, not Mono-infested, and has better licensing.

KDE is still community-driven and community-developed, so they don't have a strong lobby. It's easy to shit on volunteer developers, and a common Linux-user pastime. THAT is the real sense of entitlement.

[pingufunkybeat]

OK, that last post was unnecessarily trollish, but I can't delete it, and I can't edit it because of the braindead rules. Michael hates the posters here. Sorry about that.

In any case, KWin is used daily by perhaps a hundred million people. Anybody who doesn't think that this makes it very important is just a religious zealot.

[mat69]

OK, that last post was unnecessarily trollish, but I can't delete it, and I can't edit it because of the braindead rules. Michael hates the posters here. Sorry about that.

In any case, KWin is used daily by perhaps a hundred million people. Anybody who doesn't think that this makes it very important is just a religious zealot.

Still you can use KWin without compositing. Reducing KWin just to compositing is wrong itself.

[monraaf]

OK, that last post was unnecessarily trollish, but I can't delete it, and I can't edit it because of the braindead rules. Michael hates the posters here. Sorry about that.

In any case, KWin is used daily by perhaps a hundred million people. Anybody who doesn't think that this makes it very important is just a religious zealot.

Reality is that mesa could do with a lot more developers to make the driver stack robust and error free. That's unfortunately just the way it is, ranting how the devs must use their precious time to cater to KDE isn't going to work.

Red Hat has some devs working on the driver stack, making sure the drivers work well with gnome-shell has probably a higher priority for them than anything else. Canonical with their compiz/unity desktop mostly forwards bugs. And KWin people, well they mostly rant I don't think I have to tell you which of these different types of involvement is the most productive.

Okay that's not entirely fair to KDE, as I did see some contributions to mesa from Fredrik Höglund, using a @kde mail address. Imagine if only 0.01 percent of those hundred million KWin users contributed a small amount of money to sponsor a developer to work full time on the open source drivers. That would be so much more useful than dictating how those few devs should spend their time.

[Henri]

I'll probably regret replying to this, but oh well. It seems most people didn't bother reading the actual mailing list thread.

"We Germans are direct and speak the truth" etc. Such remarks have no place in (what should be) a technical discussion.

Except that that isn't what he actually said. Here's the actual quote with some relevant context:

Sorry
that I put my frustration into it. This is unprofessional, but also part of my
character. You know we Germans are direct and I speak the truth even if it
hurts.

Couple of points:
- "I speak the truth even if it hurts." is quite a different statement from "Germans speak the truth."
- Even then, it should be pretty obvious from the context that it's a statement about Martin's own personal character and values, rather than some kind of statement of German superiority.
- Perhaps you take issue with "You know we Germans are direct". It's of course a huge generalization, but I do think it's commonly accepted that for example western Europe tends to favor a somewhat more direct approach in communication compared to for example eastern Asia. At worst the statement is simply wrong, but I'd hardly call it racism in any case.

As a reply to this thread as a whole (or perhaps this site in general...), please do some research, check facts, etc. before repeating things you read on some random part of the internet. The person you're repeating may not necessarily know what he's talking about either, and the consequences may not necessarily just be harmless flamewars.

[bridgman]

Ooooh, that's extremely interesting. According to Wikipedia OpenGL 2.0 was released in 2004, and OpenGL 2.1 in 2006. R300s were released in
2002/2003, and a lot of R400s were released in 2004. R500s saw the light of the day mainly in 2005/2006.

Are the OpenGL 2.1 features required by Kwin among those not fully supported by hardware from these generations? Is that what's killing its performance? If yes, what would be the possible workarounds?

Most of the missing features are pretty subtle, eg certain texture options aren't available with Non Power Of Two textures. Some can be worked around but the workarounds usually have a cost in terms of performance or ability to run the largest shaders so on balance it's usually better to only implement what the hardware can directly support -- but this leads to developers being accused of "lying and saying something is implemented when it is not".

The key point is that the decision about exposing specific bits of OpenGL support is rarely as simple as people think, not only during initial development (which was how this issue blew up in the first place) but even after support has matured.

[pingufunkybeat]

And KWin people, well they mostly rant

That is quite unfair, considering that there are three active KWin developers, and they are all unpaid volunteers. It's unreasonable to expect them to have all versions of Mesa from 7.6 to 7.11-dev on all possible chipsets and test all of them.

If a large distribution paid one of them to work on it full-time (like they do with Gnome-Shell and Mesa drivers), I'm sure that the results would be very different.

[Henri]

Most of the missing features are pretty subtle, eg certain texture options aren't available with Non Power Of Two textures. Some can be worked around but the workarounds usually have a cost in terms of performance or ability to run the largest shaders so on balance it's usually better to only implement what the hardware can directly support -- but this leads to developers being accused of "lying and saying something is implemented when it is not".

The key point is that the decision about exposing specific bits of OpenGL support is rarely as simple as people think, not only during initial development (which was how this issue blew up in the first place) but even after support has matured.

Yeah. Though in the specific example you mention, I think everyone would have been much happier if ATI at the time had just created some kind of "conditional NPOT" or "normalized texrect" extension.

[bridgman]

Yeah. Though in the specific example you mention, I think everyone would have been much happier if ATI at the time had just created some kind of "conditional NPOT" or "normalized texrect" extension.

I was under the impression that ARB_texture_rectangle was supposed to provide an extension which better matched hardware capabilities, although AFAIK it doesn't use normalized coordinates. Am I close ?

[Henri]

I was under the impression that ARB_texture_rectangle was supposed to provide an extension which better matched hardware capabilities, although AFAIK it doesn't use normalized coordinates. Am I close ?

Yeah, texture_rectangle gives you NPOT textures with limitations, but no normalized coordinates.