Open-Source GPU Drivers Causing Headaches In KDE 4.5

[Hephasteus]

You don't live in the real world either though do you.

advertising features and those features having bugs or limitations is quite normal.

Dave.

There's no need to be defensive. Gallium 3d has only been going for 2 years or so. It's making fantastic progress given how few shoulders it is resting on. Just do your thing and don't worry that you won't be appreciated.

[V!NCENT]

If the Gnome devs think that making short-term succes decisions and bugged by design is a good thing then good for them; short-term succes. I hope they like it,

KDE is no longer just Linux only, in case you missed it. It is an independant island that likes to create desktop software. Plasma runs on Windows too. That makes the project OS agnostic and if KDE wants to compete with other popular desktops, like Explorer on Window, then they are going to require this tech. This fals under the catagory "DUH!" and "Whoooosh".

Where KDE is being totally stupid, and where everyone in this thread has been too, is just how fscking simple and obvious the solution is.

Kwin can use multiple backends for compositing. On Linux this is currently OpenGL and XRender. FFS chop up the OpenGL backend choice into OpenGL 1.5, OpenGL 2, OpenGL 2.1, OpenGL 3 and OpenGL 4. How fscking hard is that? nVidia blob users can enjoy the latest proprietary candy, KDE can advance to new hights and KDE will keep offering the best functionality that FLOSS graphics can leverage.

That leaves Mesa just where it is and once Mesa can be used for newer OpenGL versions then users can choose to run KDE in a newer OpenGL version. This totaly eliminates every problem on the planet and puts the ball in Mesa's court, where it should be: "What OpenGL version compatibility does the Linux desktop offer?".

[bridgman]

I don't think the issue here is appreciation or defensiveness. We're all saying "hey, the fundamental problem here is that for whatever reason KDE is expecting a level of functionality and consistency that does not exist in the Linux user base today, and trying to find someone to blame for the resulting problems is a non-starter".

The problem with a blacklisting approach is that unless something else changes nearly every hardware/driver combo out there is going to get blacklisted at some point, and the task of maintaining the blacklist will quickly become unmanageable without some kind of very sophisticated crowdsourcing solution. Martin mentioned the problem of ever-growing number of combinations. It also sounds as if the blacklist was based only on usermode driver, which becomes a problem as more driver functionality moves to the kernel and as more mixing & matching of drivers and patches takes place.

There are only three obvious solutions I can see :

1. Reduce the level of driver functionality used/expected by KDE to a level that can be fairly reliably supported across the user base, ie somewhere in the GL 1.3 to GL 1.5 range with a couple of exclusions (eg gl_arb_multisample). This is unattractive because it increases the workload on the KDE developers, who like everyone else are trying to do wonderful things with limited resources (ref. Martin's comment about using shader assembler vs GLSL).

2. Accept that for at least the next year KDE requirements are going to be "right on the hairy edge" of what the drivers support, and that only a careful collaborative effort is likely to succeed. Define a mutually agreed subset of GL 2.x functions (possibly with some GL 3/4 low hanging fruit), use only that subset (KDE) and try to keep that subset working (Xorg). This seems the most feasible, and could include a combination of KDE folks at X conference, X folks at KDE conference, online collaboration, adding KDE-specific tests to piglet etc...

3. Wave the "magic resource wand" and suddenly have 10x-50x the development resources available for driver development, so that drivers can live up to the high ideals expected of them. This would be great but the entire open source community has been looking for that damn wand for at least a decade now with little success.

If you read back through this thread what you'll essentially see is a lot of people arguing for #2. Writing those comments off as "defensiveness" misses the point IMO.

[bridgman]

If you read back through this thread what you'll essentially see is a lot of people arguing for #2. Writing those comments off as "defensiveness" misses the point IMO.

And, of course, just as I type this Vincent is also arguing for a variant of #1. Not ignoring you

Having a couple of back-ends (could be as simple as 2 although 3 would be better) would be great if the KDE community could resource the work. I don't know enough about the current code structure & "who does what" to judge the feasibility but if the back-ends were carefully chosen then it could solve a lot of problems.

Only concern is that the "safe level of functionality" (probably the *middle* back-end) is going to creep upwards with time so at least two back-ends would need to constantly evolve upwards. Given that, a single "not quite GL 2 but close, advancing with the drivers" back-end might offer the best tradeoff between effort and results for the next couple of years.

EDIT - reading through the comments on Martin's blog there were messages from other app developers (eg Stellarium) facing similar problems (issues go up exponentially as they use "still being developed" driver features, same experiences re finger pointing etc..). Establishing and maintaining a "we recommend apps use these functions" list could possibly help a number of app development teams, not just KDE. The key point here is that when driver code is undergoing incremental development (which is a reality given the available resources) the simple on/off mechanism used to expose extensions and GL levels doesn't really cut it. That said, I *think* this is primarily a transitional problem so going to a much finer grained extension mechanism probably isn't worth the effort, but a temporary "hey, we think this stuff should be safe to use most of the time and blacklisting the exceptions should be manageable" list probably is.

[V!NCENT]

And, of course, just as I type this Vincent is also arguing for a variant of #1. Not ignoring you

Yes. You are saying this is unfeasable and puts a lot more on the shoulders of KDE developpers. And you are correct at that.

The fun part is that that is the only way to have a properly functioning KDE on it's core platform. I think that a "must at least work properly"-choice should simply be made.

Now if that means that KDE can't advance to OpenGL 3, because it's possibly too much work for them, then you simply shouldn't.

Please all keep in mind that:
-People converting from Windows to Linux do so because the quality of Windows sucks.
-"Some additional fancy effects" Vs. "being actualy able to run KDE" should be won by "being actualy able to run KDE". This should be KDE's primary concern; getting as large a userbase as possible. Nobody wants to create software that nobody will use. No brainer here.

Luckily there is also Compiz in case the Kwin team chooses to screw up.

[TemplarGR]

First of all, to all those who disagreed, i am sorry but Trolltech DOES lead KDE development. You may hate to admit it and that's ok, but that may be because you never bothered taking a look at KDE's contributors... I did. And they are mostly Trolltech in key positions.

Just because a brazilian wrote a plasma applet for example, doesn't mean that KDE is strongly affected by him. The direction it takes is mostly decided by Trolltech.

And Vincent is a KDE fanboi and writes nonsense as usual.

Why does it matter to us that KDE runs on Windows or Macs? Are we supposed to care now? We are using Linux or BSD's for a reason. What's the point of using KDE on top of other platforms? If i wanted to use Windows, i wouldn't need KDE...

In reality, the fact that KDE now is platform agnostic alienates it from the platforms it draws its strength from... If they keep going on like this, KDE will die. It will alienate Linux and BSD users, and Windows and Mac users WILL NEVER CARE ABOUT IT. It will simply become irrelevant...

[bridgman]

I updated the XDS2010 proposed topic list to include this issue (closing the loop with app developers, not "the drivers suck" ).

[pingufunkybeat]

First of all, to all those who disagreed, i am sorry but Trolltech DOES lead KDE development. You may hate to admit it and that's ok, but that may be because you never bothered taking a look at KDE's contributors... I did. And they are mostly Trolltech in key positions.

Then you won't have a problem giving us a list of these developers.

Trolltech is TINY.

They did recruit several high-profile KDE developers in the past, but these developers mostly work on Qt, and not on KDE nowadays.

I've been following KDE development for 10 years, btw, mailing lists and all that. If you can name three guys who get paid by Trolltech to work on KDE full-time, I'll give you a cookie.

The fact is that KDE has always been less corporate-sponsored and volunteer-driven than GNOME. This was another one of the arguments against KDE, back when corporate support boiled down to Trolltech working on Qt. That volunteers can't write code that can compare to the professionals from Eazel, Ximian, and the like.

[pingufunkybeat]

more volunteer-driven

screw the edit limit.

Here's some reading for you: http://www.kde.org/community/donatio...t_sponsors.php

[RealNC]

I think some people here are missing the fundamental issue. KDE is just one use case where the slow progress of the Linux graphics stack is hurting advancement. The lack of proper GL support means Linux in general is staying behind. There are other applications out there that would need a proper graphics stack. When someone develops software for MS Windows, then there's no issue about whether it supports GL 3 and whatnot. But when one considers Linux, it has to be treated like some outdated, left-behind OS from the past decade where half the users have it working, the other half doesn't.

It's just that KDE is now hitting that wall and talks about it. Others did hit the same wall, but they stay silent because they don't really care (Linux market share.) KDE does care about Linux, and since they have an open development process, they talk about it openly.

You should view this as a plus. Also, if KDE can't advance itself due to lack of features, then other projects and products can't either, for the same reason. And that means Linux will never "get there."