Open-Source GPU Drivers Causing Headaches In KDE 4.5

[phoronix]

Phoronix: Open-Source GPU Drivers Causing Headaches In KDE 4.5

Martin Grä�lin, the KDE developer known for working on KWin and working on advanced features like OpenGL 3.x compositing in KDE 4.7, has written a new blog post in which he details some of the driver issues currently being experienced by some users of the recently released KDE 4.5 desktop...

http://www.phoronix.com/vr.php?view=ODU3MA

[Hephasteus]

What can they do? They gotta build the whole house and fix what's broken. I think everyone is expecting decent working 2.1 support at end of year releases. And I don't think everyone is expecting 3.0 and 4.0 to work perfectly till next end of year releases.
Die shrinking is slowed to a crawl so 4.0 is end of the line for many many years. But still best get there as quick as possible as it will be selling cards for quite some time.

[aaaantoine]

What about AMD?

Ever since I upgraded to KDE 4.5 my display flickers when switching windows when Compositing mode is enabled.

[aaaantoine]

(Graphics card is a Radeon Xpress 1100 -- or 200 depending on who you ask.)

[allquixotic]

The KDE developer's surname is all messed up in the forum post, Michael, but it shows up fine in your news article.

I want to say that I enjoy this kind of article because it draws attention to the issue of open source graphics drivers being highly inadequate. I can definitely see progress being made, but barely-adequate 2d acceleration and mostly-supported GL 1.x is no longer acceptable.

Of the few GL-using applications I have seen rendered correctly on Mesa, most of them I can think of have been written in a way that specifically works around limitations of, or bugs in Mesa's GL implementation. The quantity and severity of these bugs, in general, far exceeds any other hardware-accelerated 3d driver I have encountered. But for Mesa's openness, this would make Mesa an inferior product. My judgment here comes from years of using Intel's driver, months of using nouveau on nv40, months of using r300c, and most recently, r600c on evergreen.

Since I started using Linux in 2002, what happened? Well...

-Lindows / Linspire, which I started on, came and went
-I switched from using Linuxant, to Ndiswrapper, now to mainline kernel open source drivers for my wireless chipsets
-I switched from using Legacy OSS, to ALSA/dmix, and now PulseAudio; current-generation distros and their applications support PulseAudio, in general, extremely well
-The Ubuntu project was created and it has taken off to becoming the most used Linux distro on desktop computers
-Phoronix was founded and established itself as a prestigious review site and benchmark software developer
-fglrx has gone from barely supporting Linux at all, to being rewritten to use the same core on all platforms, and making that core render high-performance OpenGL 4.1 with very few issues
-Mesa has added a few new hardware drivers and moved its advertised OpenGL support from 1.2 to 2.1, with 3.x in the experimental (i.e., mostly broken) stages

It seems, out of that list, that Mesa has been doing the least over the past 8 years. I acknowledge the great achievements that have been made in the way of KMS, DRI2, GEM and so forth, but these projects and the way they disrupted development and developers have set Mesa back by many years, where progress was mostly stalled as developers waited for the memory manager and modesetting to take shape before they could work on 3d support. Then Gallium came and divided effort in half between the gallium and classic DRI drivers.

KDE 4.5 just highlights that we will soon be dependent entirely on closed source drivers if we want to have a competitive, visually attractive, dynamic desktop with hardware-assisted graphics. Because we can't count on Mesa to catch up; they've been playing catch-up for 8 years and have barely started to scratch the surface. And it's not just the breadth that is lacking; the depth is also lacking. Just because Mesa says it "supports" GL 2.1 and many extensions doesn't mean squat about the performance and reliability of these features when actually exercised, as KDE 4.5 reveals.

I was mistaken when I thought that audio would be a more showstopping issue for the Linux desktop than graphics. I was under the assumption that either the open drivers would catch up, or the proprietary drivers would support the same APIs the open drivers do (e.g. KMS). I was wrong on both counts. Audio problems have disappeared into the periphery for me; I rarely have any audio issues at all when using a modern Linux distro. But regardless of whether I'm using ATI's proprietary driver or the open drivers, I have always been disappointed by the graphics stack.

I had a good chuckle when Linus declared the GEM stuff "UNTESTED CRAP" in '08 or '09 (it made Phoronix headlines; can't remember exactly when it was). A couple years later and I still fully agree with him.

Can anything be done to improve the quality, rendering correctness, and performance of Mesa across the board, or will it remain in catch-up mode indefinitely? Do we really have to resort to proprietary modules to get a 99% conformant OpenGL implementation? To date, the answer is an unambiguous "yes". Even relatively conservative app development areas -- desktop software like Gnome and KDE -- are starting to approach areas where Mesa's feature set simply can't deliver. It's one thing if your latest 3d game won't run on Mesa; it's entirely another when a mainstream free software desktop environment won't run on Mesa.

So what is the heart of the issue? Are graphics drivers just so difficult a domain to understand that getting community contributions is difficult to impossible? Sure, any developer can spot an obvious NULL pointer bug, but figuring out why random horizontal lines are rendered on the desktop is far from clear-cut. We need more contributors who are intimately familiar with 3d graphics domain knowledge, and are thus more able to diagnose and resolve issues like the ones described in the article.

My impression is that, while community interest in improving the graphics drivers is very high, the actual number of community members who can contribute significant code to mesa or a DDX is very small. We have a lot of people, even software engineers, who want to contribute, but who don't know where to start, or have been thus far unable to invest the time needed to acquire graphics driver domain knowledge, a prerequisite for making meaningful contributions.

One obvious way to bring on these developers is for hardware companies such as ATI, Nvidia and Intel to pay employees to work on the drivers. Short of that, I have yet to see a strategy presented by anyone that would help the X.Org community find or train new developers who are not otherwise employed by the graphics industry as a driver developer. I saw that this was a topic for XDS 2010, so hopefully this issue will start to be addressed. At least some people recognize that it is a problem.

[not.sure]

In other (meaner) words: KDE developers have finally lost touch with the realities of the linux graphics stack.

[deanjo]

In other (meaner) words: KDE developers have finally lost touch with the realities of the linux graphics stack.

Actually it's more like the linux graphics stack has lost touch with what is actually needed. The KDE developers are well aware of the stacks short comings.

[Ex-Cyber]

If there are reasonable defaults and fallbacks where necessary, I don't see what the problem is with using some of the more advanced API features. Developers should be cautious in requiring new features, but they also shouldn't need to pretend that it's still 2001.

[brent]

KDE developers are cautious enough - OpenGL 3.0 is a few years old already. And they're only using 2.x so far, which is a 2 years older even.

I cringe everytime I see "freetards" making the bold statement that the open source drivers are great - they clearly aren't if you need anything more than basic 2D acceleration.

[bridgman]

I don't understand the comment about "KDE developers being cautious enough" -- the fact that "OpenGL 3.0 is a few years old" (actually 2 years) doesn't mean much if most of the target hardware/driver platforms only picked up OpenGL 2.x support very recently and anything past GL 1.5 is still a bit of a work in process.

The real question is "what hardware/driver platforms is KDE targeting ?".

If the goal is to deliver the best possible experience on 50% of the installed hardware base and then only with proprietary drivers, going with GL 3 now is fine, but if the goal is to run on most of the relatively recent systems out there then KDE needs the ability to run well on a GL 1.5 system and we need some collaborative planning between KDE and Xorg developers to make effective use of the available GL 2.x support.

The discussion does not have to happen at the X summit but it would be a great idea to have at least one session covering "what are we committing to make work for app developers ?". I have heard a few comments that "released" open drivers currently expose some extensions which are known not to work -- I haven't had time to dig into this but if it is the case *and* the exposed extensions are not required for other reasons (see **) then turning those extensions off for now might help the situation.

Anyways, I don't know all the answers but there's no question that relying heavily on driver features which are still under development is bound to cause pain for everyone, and the real solution needs to be avoiding the pain.

The blog post was very useful in terms of making sure everyone understood that the issues were more than simply "KDE bugs", but obviously "blaming the drivers" is not really any more useful than "blaming KDE" in terms of making happy users. The problem is a mismatch between what KDE uses and what the drivers reliably support, and trying to "find fault" (ie determine which community of volunteers to blame) isn't going to solve the problem. I don't think the blog author was doing that, I'm just mentioning this before people start piling on and blaming either side

We need to identify a set of features which can be reliably used on all of the target platforms, and then apps need to implement an appropriate set of functionality using only those features.

** the unknown is whether unsupported extensions are being exposed in order to meet a GL level, which in turn is required because apps are checking GL level rather than specific extensions but will actually run well *without* requiring the unsupported extension as long as the appropriate GL level is advertised.

Words cannot describe my hatred of the one minute edit rule.