Martin Takes His Mesa Issues To The List

[kraftman]

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).

It's good to hear this. I supposed mainly OpenSuse volunteers interests about KDE, but it seems it's not true.

[pingufunkybeat]

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.

They were limited to OpenGL 1.5 2 years ago.

[RagingDragon]

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.

[Awesomeness]

Trying to hide bugs never works.

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.

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.

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.

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!

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.

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.

[pingufunkybeat]

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.

[RagingDragon]

Since they had already provided KWin notice that they were doing it wrong, why do they have to stay up to date on all of the downstream code and follow up to make sure that KWin was really updated? You seem to think Mesa devs have nothing better to do so they might as well follow up on every project that might use their libraries. Mesa served notice that KWin was doing it wrong; at that point KWin should've fixed their code OR asked for clarification. Neither happened.

People have a hard enough time keeping up with their own code to have to consider how people downstream might be misusing their code.

However, it was flaws in the mesa drivers which forced Kwin to do the "wrong" thing.

The drivers are supposed to report what features they support, and Kwin tried to do the right thing by querying the drivers. However some drivers crashed when queried. Other drivers would claim to support features, then crash when those features were used. To work around these mesa flaws Kwin instead used the drived identification strings. The mesa devs complained about this, but didn't offer Kwin any workable alternatives.

[RagingDragon]

The point is they test drivers if they work with gnome, but it seems they don't do the same when comes to KDE. KWin developer at least tests some drivers on different platforms (not that much, though) thus he's able to make some blacklists.

And this is not true. If he would care only about nvidia there won't be any white and blacklists.

I'm not able to change a thing and devs are free to do what they want. I simply said what I think. If os drivers will be crashing in KDE I'll simply switch.

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.

[RagingDragon]

No he hasn't, and he's said he won't do so in a stable KDE release because of the possibility of regressions. So he's waiting for KDE 4.7.

Ubuntu has fixed the issue by patching Mesa to add GEM back into the intel driver string. Apparently the Fedora guys want an actual fix, so it's not yet clear if they will create the patch themselves or if KDE will make one for 4.7 and Fedora will just backport it.

Ah. Well those are significant bits of information, and which obviously change my perspective somewhat.

[RagingDragon]

It depends, when you look at debian i would not say that sid is the best branch. It is ok, when you are experienced and you can handle the things which usually happen. But is a pain to support lots of others which ran in into problems. I did that and it was no fun at the end. Also debian got maybe a bit outdated too due to the long freeze. I do not use arch (or gentoo) however, but i prefer the way of selected backports. I have got no problem when there would be a kde 4.x backport repo. It just has to install without problems. It is basically a good thing when you have got a stable system you can base your updates on. Of course not every package will be the latest one possible, but is that really needed? I had to patch a handfull of lines to compile nouveau with xserver 1.7. I get most likely the same speed as when you run 1.10, so what did you gain?

It isn't necessary for a rolling release distro to have bleeding edge versions of every piece of software. Slackware being the prime example of this. You are correct that frequently updated backports are another way to achieve the goal of getting important fixes to users on a timely basis.

[Beeftneavaink]

Martin Takes His Mesa Issues To The List

Can I ask a question to Martin, "what has been your best ever money saving tip?"