If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I was using xf86-video-ati and KDE together for a year or two without incident. My main problem with the open source drivers is lack of game support

I think that pretty much all the native Linux games work with OSS radeon drivers. There are only very few exceptions, and I can't think of many. Trine has messed up lighting, but this will be fixed in git soon, and I can't think of any others. Oil Rush, when it's released, maybe.

The major issue for existing games is performance, but most things are playable.

I don't know for intel or radeon, but clearly, nouveau is not even polished-enough to accept crashes report (only mis-rendering bug reports are accepted).

I find your comment amusing. First you don't want to hide bugs but then you don't even accept bug reports for anything but cosmetic glitches.

Here's an idea: Fix your bugs and don't just leave them unhidden, rejecting every incoming bug report that's not about a cosmetic issue.

Originally Posted by MùPùF

People can't expect things to work flawlessly when a driver is experimental.

That's bull.
Red Hat releases Nouveau as part of every Fedora release since quite some time (and it's also part of RHEL 6). And Red Hat has AFAIK one Nouveau developer as employee.
That means: Every 6 months there is an actual Nouveau release that has to be release quality and the RH guy in your team is the one who has the responsibility to achieve it.

Originally Posted by smitty3268

I think they did say - it's whatever projects they are actually being paid to support. I'm certain there are some Red Hat or other devs being paid to make sure that Gnome Shell or Compiz are working. Apparently none of the distros have ponied up to make any developer responsible for KWin support.

Novell used to have Lubos Lunak as KWin maintainer but Novell assigned him away from KDE to work on LibreOffice instead.

Originally Posted by bridgman

it just seems that relatively more of the developers working on the drivers use gnome than use kde.

What a nice little excuse you have there wasn't there the fact that the core developers of the Radeon and Intel drivers are employed by AMD/Intel to work on the drivers. So do your work you guys are paid for by our purchases of your hardware products!
An occasional 'kwin --replace' is the very least you high-paid developers can do once in a while!
It's absolutely embarrassing that in a later comment you blame the distributors for your bugs!

Originally Posted by pingufunkybeat

I expect the distributions to make sure that the software they ship works correctly, and I don't know how they managed to get the intel update in without noticing that KWin won't run compositing with it.

Just because some distributors also fucked up (Red Hat's KDE team members mostly work part-time on KDE stuff while Canonical made all two paid Kubuntu members work on Unity 2D because of their Qt skills), doesn't mean that the overall fault does not lie with the driver developers. Changing an ID string in a minor, bug-fix release is not something that is tolerable. Next major version: Fine. Minor release: No way!
Every somewhat professional software implements string freezes for minor versions for good reasons.

Originally Posted by deanjo

Feel free to visit the openSUSE KDE room, lots of paid devs there all the time fixing all kinds of KDE issues (actually seems to see a lot more activity then the Gnome channel).

Priorities of Novell lie with GNOME nonetheless. GNOME is the default for SUSE Linux Enterprise Desktop with Plasma Desktop rather hidden (no clear desktop selection screen as with openSUSE's DVD). Banshee, F-Spot, Evolution, and MonoDevelop are just four examples of full-blown GNOME applications written by Novell whereas in KDE software the contributions are limited to bugfixes and integration work.

I think that pretty much all the native Linux games work with OSS radeon drivers. There are only very few exceptions, and I can't think of many. Trine has messed up lighting, but this will be fixed in git soon, and I can't think of any others. Oil Rush, when it's released, maybe.

The major issue for existing games is performance, but most things are playable.

Has anyone gotten: UT2004, Doom 3, Quake 4 and/or Quake Wars working with recent open source AMD drivers? I haven't been able to find any reports one way or the other.

Uniengine uses features that aren't supported by Mesa (i.e. tesselation), so even if they get Oil Rush running on the open source drivers alot of the graphics features would have to disabled when doing so. Since my hardware supports those features, and they work with proprietary drivers, this makes the open source drivers alot less than appealing.

If/when steam comes to Linux, we can be certain it'll work with the proprietary drivers. But will it work with the open source drivers? Considering that the open source drivers are effectively limited to OpenGL 1.x, with buggy OpenGL 2.x support, incomplete OpenGl 3.x support and no OpenGl 4.x support, I have my doubts.

Has anyone gotten: UT2004, Doom 3, Quake 4 and/or Quake Wars working with recent open source AMD drivers? I haven't been able to find any reports one way or the other.

I finished Doom3 more than a year ago.

I've played Doom3, Quake4 and Prey recently, with no problems (everything renders correctly, and is fast enough).

I haven't tested ET:QW and UT 2004, but they're reported to work: http://wiki.x.org/wiki/RadeonProgram. Keep in mind that many of the reports there are outdated, and would be platinum with more recent drivers.

The last missing piece of the puzzle was s3tc for recent hardware.

Uniengine uses features that aren't supported by Mesa (i.e. tesselation), so even if they get Oil Rush running on the open source drivers alot of the graphics features would have to disabled when doing so. Since my hardware supports those features, and they work with proprietary drivers, this makes the open source drivers alot less than appealing.

Oil Rush is the first OpenGL 3+ game coming out for Linux (AFAIK). When these become commonplace, you are right, OSS drivers will have problems. There's work going into OpenGL 3+ features, but it will take a while.

But with most currently available games, they work fine.

If/when steam comes to Linux, we can be certain it'll work with the proprietary drivers.

You mean the Source engine, not Steam. Source engine is OpenGL 2. id's Rage is also OpenGL 2.

But will it work with the open source drivers? Considering that the open source drivers are effectively limited to OpenGL 1.x, with buggy OpenGL 2.x support, incomplete OpenGl 3.x support and no OpenGl 4.x support, I have my doubts.

OSS drivers support OpenGL 2.1 fully, with more than half of OpenGL3 extensions being supported.

I was using xf86-video-ati and KDE together for a year or two without incident. My main problem with the open source drivers is lack of game support (and I believe this mostly due to upstream mesa limitations, not the drivers themselves). That, combined with the difficulties in running the AMD/ATI proprietary driver on non-Ubuntu distros, make an Nvidia GPU plus their proprietary driver the only viable alternative for me.

For me OS drivers were also nearly painless till I have switched to Kubuntu 11.04beta2. It seems mesa and kwin packaged in the newest Kubuntu doesn't play good. There's few issues and I hope they will be fixed somehow.

There were a lot of options discussed - it's hard to believe that none of them were feasible :

I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.

No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

First lets have a short look at the time frame:

April 26th: Soft Feature Freeze for 4.5

May 11th: Hard Feature Freeze and Soft Message Freeze

May 26th: Release Beta 1

June 9th: Release Beta 2

June 17th: Mesa 7.8.2 BOOM - KWin starts to break

June 22nd: Hard Message Freeze

June 23rd: RC1 release

At the time we noticed we had severe problems with Mesa 7.8.2 our release was basically done. For us it is important to provide users the best possible user experience and to not release a broken release. This implies to workaround issues in drivers rather than to wait for fixes. Our users don't care whether it's the driver or the desktop which is broken. Our users want a working desktop.

Originally Posted by bridgman

- use the GL 1.5-ish code paths by default (which worked on all drivers) and make GL 2.x code paths a user option

User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

Originally Posted by bridgman

- use a (DX9-ish) subset of GL 2.x which could be supported on all of the hardware where that level of support was exposed

All our code scales down. We added better checks to 4.6 - for 4.5 it was too late due to feature freeze.

Originally Posted by bridgman

- use a small set of functional tests rather than blacklisting, discussed with driver devs to use what "should work", driver devs would prioritize anything that crashed those tests

Again: feature freeze. As a side remark, KWin had had one functional test in it's code base which started to break with Mesa in 4.5. Considering that we are not so interested in functional tests any more ;-) I am not fond at all of feature tests as that will delay the overall startup of the KDE Plasma Workspaces.

Originally Posted by bridgman

- work with the driver devs to identify a set of extensions/levels which could be used to identify drivers that would work well with KWin

This would of course have helped for 4.6, but not for 4.5. I hope I explained in my mail that at that time I was very time constrained and our priority was making KWin work with the current driver and not the next driver.

Originally Posted by bridgman

- in the worst case, whitelist for GL 2.x code paths rather than blacklist

We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)

I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.

As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.

I am not sure where those options were discussed, but no Mesa developer approached us with any of these options presented in this post. At least not on our mailing list or in our bug tracker.

The problem was that the discussion started as blog posts, which then triggered posts on other blogs, and spread around the internet that way (there were some third- and fourth-order discussions going on). The responses mostly followed the blog posts, unfortunately.

Originally Posted by mgraesslin

The post also shows that there is still quite some lack of knowledge and understanding for the needs of a large desktop environment, which was also the reason for my long post to the mailing list. I think it is very important for both sides to understand each other needs correctly or issues will come up again and again.

I didn't actually see "lack of understanding" as much as "unfortunate timing".

Originally Posted by mgraesslin

No matter that the options were not discussed with us, I want to show that in fact none of it were feasible. We internally also discussed various approaches before our 4.5 release and implemented the only feasible approach.

User option was not possible due to string freeze. User option got added for 4.6. After quite some discussions we decided to default to the GL 2.x code pathes for various reasons. One was that it was working fine on most drivers and we had the available fallbacks in place.

We did hardly receive info on which hardware/driver combo did not work. It would have been unlikely that we would have been able to identify everything for a whitelist. As a matter of fact we had a whitelist till 4.4 and it did not work well and we dropped it. If you have been somewhere you will not implement it again. And btw what got broken in Mesa 10.0.1 was a whitelist ;-)

The discussion at the time suggested that only one driver was really considered working (NVidia proprietary) which would make the whitelist pretty simple. If there was a much larger list of working drivers then I agree that would make a whitelist more difficult, but that was not the messaging at the time (it was more along the lines of "the NVidia proprietary driver works and the OpenGL 2.x standards have been out for years so if it's not working on your drivers you guys must all be stupid ).

Originally Posted by mgraesslin

I think there is some missing knowledge on how the blacklist was actually implemented. The blacklist was not hardcoded into the source code but in a kconfig file. The blacklist was setup in a way to block only very specific driver releases, so that new driver releases which fixes bugs would not be blacklisted. Furthermore by using a kconfig file it would have been possible for us or distributions to update the blacklist just by providing a simple script.

Even the needs of the Mesa devs were considered. Users who wanted to report the issues or devs wanting to investigate, would just need to remove the blacklist entries without any need to recompile KWin.

Seems reasonable.

Originally Posted by mgraesslin

As a matter of fact the blacklist implementation has been removed from KWin master some weeks ago as nobody ever updated the entries and would not have blocked anything at the time of the 4.6 release anyway as Mesa 7.10 had been released and the blacklist at max blocked 7.9 development releases.

OK, maybe a dumb question but if the blacklist was removed some weeks ago and the recent mesa change broke a whitelist did the whitelist replace the blacklist ?