Open-Source GPU Drivers Causing Headaches In KDE 4.5

[Kano]

Hellfire uses 4.4.5. Seems to be better suited for you.

[Smorg]

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?

Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch. I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.

What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).

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.

They are more stable and better supported by distros. I've had way fewer issues with open source drivers than blobs. Open drivers are the only sane long-term solution.

[xeros]

It seems to be mostly older Intel drivers causing issues. Does everything work with the current git master?

The main reason they want to start using OpenGL2 is so they can port KWin to OpenGL ES and run on mobile devices. Sounds like FBOs are one of the main OpenGL3 features they'd like to use, but they will retain backwards compatible code for it. Other stuff like geometry shaders might be used in advanced effects only, or with alternative lower-quality backups in place.

Is FBO supported on R300 devices?

[bridgman]

Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch.

Yep, although a few new developers do manage to jump in every year, which is impressive. The most important pre-requisites seem to be (a) understanding OpenGL, (b) enough of an interest in hardware to pick things up quickly via (c) quick learning & good communication skills in order to be able to interact well with the rest of the developers on IRC and "learn as you go".

I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.

There are maybe a couple of dozen in total spread across all the HW brands. There is a *lot* of common code, particularly in Mesa. Remember that agd5f worked on the open source drivers for ~7 years before he came to work at AMD, and the same goes for a lot of the other devs. The guys working for AMD (or Intel) have access to internal information so there is a specific class of "make new HW run for the first time" work that only they can do, but most of the development effort is going into improving the drivers using already-available information.

What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).

I don't understand this comment unless you are talking about r200-class hardware or are using the (relatively stagnant) "classic" mesa drivers -- 3 years ago there was almost no 3D support available on anything past r200, now there is fairly significant GL 2.x available on nearly all post-r200 hardware. Are you running the Gallium3d drivers (which are improving rapidly) or the classic drivers (which aren't changing much) ?

[sundown]

OK, so who is going to fix the annoying kwin compositing flickerings and blur effect in the end?

[hteles]

Gallium3D

Hi everyone,

i've registered myself so i can tell you about my experiences with gallium3d.

I'm one of those guys that were hit by the recent slowdown and loss of desktop effects with the recent kde 4.5.1.
I'm currently running ( as always do ) the testing branch of kubuntu Maverick. I work in linux as a living and have been lucky running development versions of kubuntu now, and slackware till recently.
So after digging and reading this thread from the begining i decided to try gallium for the first time and all i can say is, man, you are doing a great job and for any of you who are having problems with kde 4.5.1 and like i, do have an old ATI radeon x700 or something similar and are running any *ubuntu version, give https://launchpad.net/~xorg-edgers/+archive/ppa a try. My desktop is running a bit faster and i've got my desktop effects back.

Also, take a look at http://apachelog.wordpress.com/2010/...cs-system-kcm/ i've compliled mysef but it will be merged to kubuntu maverick, it is already at maverick changes mailing list. My desktop feels snapier with raster as qt graphics rendering.

My specs
helmer@zen-mobile:~/incoming/src$ glxinfo |grep -i opengl
OpenGL vendor string: X.Org R300 Project
OpenGL renderer string: Gallium 0.4 on RV410
OpenGL version string: 2.1 Mesa 7.9-devel
OpenGL shading language version string: 1.20
OpenGL extensions:

helmer@zen-mobile:~/incoming/src$ lspci |grep -i vga
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X700 (PCIE)

System Information
Manufacturer: Acer, inc.
Product Name: Aspire 1690
Version: Not Applicable

BIOS Information
Vendor: Acer
Version: 3A45
Release Date: 04/21/06
Address: 0xE79A0

Thank you all.

[smitty3268]

No, doesnt' work. I already tried. Opengl composite is totally disabled, at least on kde 4.5.1 ubuntu maverick. And it was working superb! on 4.4 once u disabled blur.

The solution seems pretty simple to me, disable blur on intel integrated drivers, and TA-DA ! it works, but KDE only test on nvidia hardware, pfff.

You can edit the blacklist manually if you want. See http://blog.martin-graesslin.com/blo...-kwin-effects/ for details.

It uses KWin?s default KConfig file (~/.kde[4]+/share/config/kwinrc) and uses KConfigGroup "[Blacklist]". The blur effect uses the sub-group "[Blur]", while the Lanczos filter uses the sub-group "[Lanczos]"

[kazetsukai]

Absolutely. It isn't just the drivers but understanding X, DRI, MESA, the hardware, 3d graphics in general. This is hardcore stuff and a massive codebase which no weekend hacker is going to be able to touch. I'd say about the only guys who have the expertise are probably the 2 working for AMD who actually work on this. Thus, Linux graphics are about the most bitched about but least worked on problem domain.

There is lots of work being done to reduce the complexity of this development all the way from the kernel down to the X Server. Legacy code will always be a mess.

What confuses me is that they do appear to be working at a feverish pace judging by the commits, yet nothing they do appears to have any tangible benefit on the user end. My 3D stuff runs exactly as it has for years. I never ever notice something magically start working which didn't previously (And I'm even running live mesa and radeon ebuilds on Gentoo).

You can only get the real information by looking at the actual commits and any associated notes with them. You can't honestly think that nothing of value is being done?

They are more stable and better supported by distros. I've had way fewer issues with open source drivers than blobs.

Man, this argument, I am tired of hearing. I have the exact opposite experience, others will have similar or unusable experiences, regardless of what driver they're using. If by "more stable" you mean your display wont go down as often, you may or may not be correct. If you look at the following equation:

(Total Number Of Features, equally weighed)
*
((Value of Downtime caused by instability (100 being impossible to use, 0 being perfectly stable))/100)

You will -ALWAYS-, and I mean -without exception- get a higher number on the blobs. Period. That makes the blobs more stable in my book.

The problem outlined in this article is exactly what countless users have complained about, but the (as another user called them) "freetards" on these boards have been adamant about feature parity and functionality not being a priority over freedom. Computers aren't toys, they're productivity tools. Tools which are worthless unless they work.

I as a web developer have gotten sick of certain browsers not supporting newer web technologies, such as CSS3, certain JavaScript, and HTML5. Guess what? It got too annoying to try and support all of the ieTards, so I don't bother to code browser-specific workarounds anymore. The same is true of graphics on Linux- its so frustrating to have to conditionally add features based on both hardware and driver limitations - why force these limitations on application developers? The standards are there, and have been there for years!

I don't think slamming the KDE developers for adding new features is right. Doing so is basically telling the entire industry to bottleneck itself by waiting for the open drivers to play catch up, and by 4,5, sometimes even 6 years. I'm up for ditching the open driver support over slowing down the industry.

[kazetsukai]

Ugh, post edit limit.

Correcting my above equation:

0 being Impossible to Use;
100 being Perfectly Stable.

[Smorg]

I don't understand this comment unless you are talking about r200-class hardware or are using the (relatively stagnant) "classic" mesa drivers -- 3 years ago there was almost no 3D support available on anything past r200, now there is fairly significant GL 2.x available on nearly all post-r200 hardware. Are you running the Gallium3d drivers (which are improving rapidly) or the classic drivers (which aren't changing much) ?

You can only get the real information by looking at the actual commits and any associated notes with them. You can't honestly think that nothing of value is being done?

Yes classic drivers. I have both compiled but haven't tested switching over as from what I've read Gallium doesn't quite offer any advantages yet - I would assume especially on my r700 as Gallium3d support is still so new. I'll probably try switching as soon as that changes.

The problem outlined in this article is exactly what countless users have complained about, but the (as another user called them) "freetards" on these boards have been adamant about feature parity and functionality not being a priority over freedom. Computers aren't toys, they're productivity tools. Tools which are worthless unless they work.

I understand the pragmatic concerns of users and don't mind those who use blobs if they must, or who write software incorporating unimplemented standards - provided that they really are standards, not proprietary or patented non royalty-free extensions, or otherwise standards whose purpose is merely to impose vendor lock-in and incompatibility.

I don't however understand why some people fail to see the pragmatism in free drivers. Blobs are merely a stop-gap measure. Perhaps even more important than freedom is the assurance that hardware can be supported in the absence of an IP or Copyright holder with the necessary commercial and economic motivation to support a proprietary driver in a free-software friendly way. Remember companies won't hesitate to write crippleware or make changes which force other software to make less-than-ideal changes in order to interoperate if it is in their interests to do so.

Even if they're fine for now, that's no guarantee of what might happen 5 or 10 years from now. Imagine if Oracle rather than Nokia bought Trolltech and some big wig decided "you know what, screw you kde guys. From now on we're going to exclusively offer our clients all of the unique advantages that can only come from our innovative ideas which are just way too clever for anybody but us to think up, so we'll patent them and sue anybody else who tries to copy our brilliance". Then you end up with a fork, which is just fine, but having a free implementation is a prerequisite for that.

Back to the point... I would probably use the blobs if I needed such high performance graphics. I don't really at this point. Actually I run KDE with Xmonad anyway so Kwin isn't as much of a concern here.

I as a web developer have gotten sick of certain browsers not supporting newer web technologies, such as CSS3, certain JavaScript, and HTML5. Guess what? It got too annoying to try and support all of the ieTards, so I don't bother to code browser-specific workarounds anymore. The same is true of graphics on Linux- its so frustrating to have to conditionally add features based on both hardware and driver limitations - why force these limitations on application developers? The standards are there, and have been there for years!

I don't think slamming the KDE developers for adding new features is right. Doing so is basically telling the entire industry to bottleneck itself by waiting for the open drivers to play catch up, and by 4,5, sometimes even 6 years. I'm up for ditching the open driver support over slowing down the industry.

Completely agree on both counts. Hell, I serve my pages as application/xhtml+xml because I really just don't give a f**k about IE. IE is a terrible analogy with this situation though. There's no reason to care about an inferior proprietary implementation when free alternatives are readily available - just because the world is filled with idiot IE6 users. "You mean that thing that gets me to the internet after dialing in to AOL?" ... But that's a rant for another day.