Heck, late kernel/Xorg support is the least for me. Compared to things slugginess and lag I often have on the desktop(it's MUCH less with radeon). Pretty much everything fullscreen and hardware accelerated is glitched. Right clicking on a fullscreen youtube video temporarily glitches up graphics for a moment and then no right click menu. Sometimes there is, but it's invisible. In fact when running a game or anything that combines fullscreen and hardware acceleration(flash in chrome). I can't see anything else other than the fullscreen thing, no matter what I do, except in between glitchy graphics when I alt-tab, activate a hot corner, etc, It's really annoying .. You can see it happened, but you're still shown the fullscreen window. Sometimes by moving the cursor around I can see the windows in expo mode when it happens due to the corresponding hot corner, and then a glitched texture makes a sort appearance before the fullscreen window is again falsely displayed, since I interact with the expo mode. Same with workspaces hot corner and more. Pressing media keys also glitches the graphics temporarily while the sound icon is displayed when in a game/fullscreen-accelerated-window.
So recently I started using the Gala window manager. Very fast, fluid, smooth. Even the previous bug didn't happen in many cases. BUT screenshots would show some random image of another window not in forefront or just background(some buffer madness must be going on there), transitions when logging in/out seem very glitchy(glitchy textures like usual), games/fullscreen-accelerated-windows present me with a nice purely black screen and similar goodness.
So I found a way to cure these bugs surprisingly! Yeah, you guessed it! "sudo cp /usr/bin/gala /usr/bin/gnome-shell && gnome-shell --replace".(WTH?)
You might say "what?". People more familiar with Catalyst may understand though. Catalyst works very well in general(as described previously ..) so many application specific hacks are used(I could say tweaks, fixes, but hacks is probably more correct). It appears that it severely breaks mutter based window managers, so more hacks were added for that(who would guess?). But Gala (and apparently Cinnamon) are not on the list to get "fixed" and miss on all that goodness resulting to mentioned bugs. But by using an appropriately named executable file I was able to activate them. So here's the thing. While all the bugs that mentioned for Gala were gone now, all the previously mentioned issues suddenly appeared... xD
Now I so hope power management for radeo comes about soon ... :/
I mean seriously .. And it's that way in many different version of many different distributions, but not with radeon(I have other issues there though, mostly my laptop emitting amounts of thermal energy similar to a nuclear reactor when just web browsing etc).
Why don't they fix this kind of stuff? And just apply more application specific hacks that bring other problems? Can't they make a driver work right? UNIVERSALLY! NO APPLICATION SPECIFIC HACKS! It's pretty obvious that the driver behaves very differently for different kinds of apps, like games, window managers and other apps. I understand performance profiles .. But this? I mean application may not work AT ALL without the hacks, while they would under ANY other platform.(by platform I mean other proprietary or open drivers)
I mean, even certain OpenGL commands just fail if not issued in certain ways/order, while they work on the other drivers.
Instead we get new performance profiles and a graphics corruption fix which isn't really a fix since it doesn't solve the issue, but causes another one apparently ..
Thanks AMD! :P
Yeah, I know, they care for "workstations". I don't recall my laptop saying workstation anywhere though, and whatever AMD card I saw/bought seemed to advertise games on it, not render farms or whatever ..
Anyways, hopefully, good times are ahead for the open radeon driver. But for me, it's just not there yet .. :/
Should I add, Elementary OS plans to blacklist fglrx from Jockey .. xD
They're not very wrong I think .. :/
Whoops, wall of text! It's probably due to my love for AMD!
Seriously, I like AMD, but just fix the damn drivers .. -.-
People, calm down with the "why u ship the latest patchorz!?!?". It's simple: it's called validation and testing.
If they haven't tested it properly yet, how do they know it won't eat your machine, or cause some big issue about corrupting data, etc.
It's not just "ship patches and pray". They could include the patches behind a non-default switch like --please-eat-my-hard-drive or something like that, but otherwise it's a good thing they don't rush to include untested stuff.
I will make the obvious switch, AMD doesn't support me, I don't support them. Future money will go to Intel/Nvidia (Nvidia by the way has already support for xserver 1.14 and kernel 3.7 and even xserver 1.13 in their legacy drivers) for sure, but as long as my systems are not obsolete to me I will further complain about AMD's crappy driver policy.
-Other people with different hardware/driver configurations are unaffected.
-I am unaffected when using a different driver on the same machine(radeon in this case).
-I am unaffected when using the program in a different machine that runs neither Catalyst or has an AMD graphics adapter.
I think it's pretty safe to assume it is a driver bug after this? Because yes, I did test all that. Did you honestly think the first thing that came to my mind that I could blame was the driver? On the contrary, it took my a while and some testing to arrive to such a conclusion. I have an older laptop with an NVIDIA GPU where I never worried about any of those while I used it. Neither was there a problem when testing on machines with Intel graphics. Neither on the same machine with the radeon driver. Am I so unlucky? On multiple different version of OSes and drivers?
Of course I try to run the latest version of Catalyst every time(13.1 now).
And put just a bit of thought on this, how were there huge differences on how a window manager behaves by just changing its name if its not application specific hacks done by the driver?
Hint: The application doesn't behave differently because it checks its own name.
Also I've read blog posts from at least one window manager developer(compiz) referencing to that. How come it be only on AMD that something like this happens?
Why is "Proper Catalyst support" one of the new features of KDE 4.10? I never saw "Proper nouveau/radeon/intel/nvidia support" anywhere.
Intel, nouveau, nvidia and radeon are probably buggy, but fglrx isn't I guess .... That's why the latter often requires special care from applications.
If you have evidence suggesting otherwise I'd gladly listen, but to automatically assume the application is buggy doesn't seem right to me.
application bug at the end.
Again, there is thread about this.I have an older laptop with an NVIDIA GPU where I never worried about any of those while I used it. Neither was there a problem when testing on machines with Intel graphics. Neither on the same machine with the radeon driver. Am I so unlucky? On multiple different version of OSes and drivers?
That's why the latter often requires special care from applications.
ONE bug on Gnome Shell was indeed application specific. Does that mean much against hordes of bugs that have been resolved(or not) by Catalyst applying hacks too applications(easily provable) and even then application applying hacks back at Catalyst cause it wasn't enough?
Still fails to answer how a bug can happen only on Catalyst. An even behave differently with the same Catalyst under different circumstances(like different application name so no hacks are applied on it).
And thanks for the thread link, but I've read this thread a long time ago, and to day it still doesn't look much different.
Btw, the bug comment you listed reads as follows:
Doesn't that mean that AMD changed their implementation of GL Shading Language on Catalyst?(At least for Gnome Shell)firstname.lastname@example.org 2012-04-24 02:42:10 CDT
thanks for the stack traces. they were really useful.
we changed our implementation for "#version" which should fix the crash.
According to glsl spec, version 4.20, 3.3 Preprocessor, Page 13,
The #version directive must occur in a shader before anything else, except for
comments and white space.
So the original operation was right. But NV's behavior looks like:
a. only preprocessor codes could be placed before "version"
b. pragma and extension can't be placed before "version"
c. the codes between "if" "else" "endif" can't contain no-preprocessor codes.
Maybe I am missing something, but why did they do that? If they are correct, Gnome devs should fix that(and even AMD devs could submit a patch simply getting the version line on top if they wanted to fix it themselves), but instead feed a vicious cycle of hacks on top of hacks?
writing patches for KWin (Jammy Zhou) - that what called "proper support of catalyst" on Phoronix.
The problem you guys are talking about here is known among Cinnamon users who have Radeon cards, and I'm one of them. I've reported this bug long ago and still have no answer from developers, but thanks to George we now know that renaming cinnamon/gala to "gnome-shell" fixes most of the problems, and I think that might help developers in their work.
BTW, Rigaldo, are you the one who posted this in bugreport I mentioned above? If not, then at least you know where to look for the additional information