Registered Member
|
Bump.
So where is the problem. Is it in my card because it supports (how many? - don't know how it checks) less shaders than it is required by lanczos filter (50)? Or simply the problem is in radeon driver and it can be fixed by X developers? Or conversily:
I am very confused. Now I have blacklisted my card and can't use desktop effect. Will I able to use it again? I miss it so much. |
KDE Developer
|
The opinion of the X developers is ridiculous. They need to make the compilation of the shader fail and not say something like KWin developers need to fix it. For us it's impossible to test with all hardware. Our safty checks rely on the driver tells us that something is not working. That's the way how other drivers handle it.
Of course we can increase the shader, but it's difficult when you don't have failing hardware. In 4.6 we have a config option to disable the filter. |
Registered Member
|
So referring from what you said is it 100% certain that driver (radeon in my case) is guilty? Maybe the decision in the mailing list was too early and not deeply thought? If I am 100% sure it is X issue I can fill a bug report. There is nothing to argue about.
Cool. Today we can get by with configuration file (blacklisting). I really appreciate your input! |
KDE Developer
|
let's say both are right. Our shader could be better but only the driver can make it fail and we can check for that (and do that). We cannot check for silent failures and there are two many drivers to really test everything.
|
Registered Member
|
Hm, I don't quite understand it (shaders, etc is a black magic for me). So please correct my thinking.
I understand that current drivers don't check if given card supports these 50 shaders and they fall silently without noticing KDE that it can support it. So now we have to blacklist (as I did) given driver in a configuration file. OK. But what's the difference whether driver tell KDE "I cannot support it" or it won't tell anything? My understanding is that in both cases card won't play nicely with lanczos. Or perhaps the following is correct: if driver tell KDE it can't do it, nifty KDE developers can't fine tune internals so that it can display desktop effects but with less quality. Excuse my little knowledge and explain it to me down-to-earth. |
Registered Member
|
This is a guess, so take it for what it's worth (probably very little): In the first case, kwin can essentially assume that it won't work. The driver tells it so after all, so it won't bother with trying to enable features the driver explicitly tells it that can not work - no matter how much the user tries to enable it. In the second case, it has to guess. It may work, and it may not. Kwin cannot tell since the driver won't tell it. The different versions of the chip, the firmware, the precise revision of the driver, and whatever else may be different between two different computers may make the guess be correct on one of the computers but flawed on the other.
OpenSUSE 11.4, 64-bit with KDE 4.6.4
Proud to be a member of KDE forums since 2008-Oct. |
KDE Developer
|
I try to explain how the shader interaction works - I think that will help to understand where the problems are. A shader is a piece of source code written in the OpenGL Shading Language and the source code will be executed on the GPU. The source code is passed to the OpenGL driver as it is and is compiled by the driver (and not in a previous step during build of kwin).
A compilation can of course fail and kwin handles this situation. It checks whether it compiled and will not use it, if it does not compile. That's quite fine. It's additional eyecandy and we can live without it. That's the expected situation. Now here we have a situation that compiling does not fail but the shader does not work as we exceed some hardware limits. That is something where I would expect the compiler to fail. It does not fail and we don't get any information that it does not work. Only the user sees that it is black instead of windows. Which is kind of suboptimal. To be honest we could check for the limits of the graphics card and not load the shader if we exceed the limits. The problem with that is that we cannot do it in an automatic way. We would have to manually count the constants in our shaders and hardcode the numbers inside kwin. This has some obvious disadvantages: we don't know how the code gets rewritten by the compile (it might add further constants), it is likely to fail (someone changes the shader code without adjusting kwin code) and there are many things to check for - not only constants. So for us the only working solution is an error reported by the OpenGL driver. |
Registered Member
|
Thanks guys! Now I can imagine how it works.
OK. But there is another aspect. I heard many had problems with lanczos, thus desktop effects. I could understand it personally because I have quite old, 4 years PC with build-in ATI Radeon card. Yeah, and it's not nifty one. But tonight I've run Kubuntu 10.10 on my brother's laptop - Dell Studio 1558 i7. If I remember correctly it's fairy new - about (or less) one year. I has dedicated car (no build-in), (yet) ATI Radeon 5470 1 GB. Sorry, I'm not hardware-savvy so can't tell how it's nifty (or how it is not). But I guess that this card in quite new hardware should play nicely with kWin effects that require lanczos (to name blur). Unfortunately it couldn't! Hence I have a question. Do you know the scale of the problem? Is is common? By the way, wouldn't you risk too much? And the most important: will users of older hardware be able to turn desktop effects on? The problem without DE is much more important than one might think. Many plasmoids are displayed badly or poorly. Yeah, and it is common. Additionally X developers tell they don't bother - it is not issue of theirs and kWin devs should deal with it. Fine. Users don't mind who is responsible - it should just work! Many of us and I appreciate your work much! As I said above - didn't you risk too much changing the code that just worked until KDE 4.5? I was happy with kWin effects - they just worked. But now others and I can't turn them on. What are you going to do? Are you going to collaborate with X developers? Cheers, KDE devoted fan! |
KDE Developer
|
Much more important than the video card quality is the driver quality. Your graphics card can be the best in the world, but if the driver quality sucks, you won't be able to use it.
Very difficult to say. From the bug repots we get it seems to be getting better. It was a very rough time around the 4.5 release and it seems all involved parties worked on improving the situation
No at the time we enabled it, it was the right decision. The decreasing quality of drivers (claiming to support features which aren't supported and missing shader compile errors) was unexpected and unknown. The issue was first noticed late in the release cycle - too late to notice how many users are affected and too late to disable it for all.
Things like lanczos are additional eye candy for users of modern hardware. This does not affect users of old hardware at all
Desktop effects are not used for rendering plasmoid. I think you suffer from a completely unrelated issue.
I couldn't disagree more - to me this is clearly a driver bug. Reasons: see my last post.
I recommend you to read http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma-in-kde-workspaces-4-5/ and http://blog.martin-graesslin.com/blog/2010/09/demystifying-opengl-desktop-effects/. It should help to understand the situation.
4.6 contains huge performance improvements and a complete new code base for detecting driver capabilities. It's not yet used all over the code, but this will change. That allows us to disable features even if the driver tells us incorrectly that a feature is supported. Furthermore we know have config options to disable Lanczos in the GUI. For 4.7 I'm currently developing a new rendering engine based on OpenGL ES 2.0 which is in the not yet optimized development state performing much better than our current rendering engine (which will be kept for legacy hardware).
Not really - I don't have the time for it and there is not much to collaborate on. I'm not going to start driver development and I do not expect that driver developers start to work on KWin. From our side there is not much to do except raising awareness that driver quality matters and that nowadays also window managers want to make use of advanced capabilities and not only games. It's out of our hands to do anything if the driver quality decreases. I think the message arrived at the driver developers and I hope they will be more careful in future - especially considering the fact that Ubuntu Unity in 11.04 will have higher hardware requirements than KWin. |
Registered Member
|
Whoa! Now I see how complex it is!
OK, I see.
Yeah, I noticed it around 4.5.1.
Now I understand that even though card in my brother's laptop is quite modern, poor quality of driver doesn't allow it to use cool effects like blur.
Recently I dented on Identi.ca that there are glitches in login screen. Then Ivan Cukic asked if DE are on. I replied that they are not. So I inferred that it requires DE to be on. Perhaps I was wrong writing this.
That's why I said at the beginning of this post that it is so complex. Oh, complex to a user like me. Now it is more clear for me. Martin, you are so nifty so I am sure you can explain me the following. The problems with desktop effects I've had since Kubuntu 10.10. As you know, Maverick came with KDE 4.5. Before 10.10 I had been using 10.4 but with KDE 4.5 thanks to backports. Before 10.10 I hadn't had problems with desktop effects (my hardware doesn't support blur so it was off). Around 4.5.1 and being already on Kubuntu 10.10 I've experienced problems with all kWin effects. With DE turn on screen is flickering while simply moving windows. mmm... I'm sitting in front of my computer and reflecting that this flickering was not related to lanczos. Maybe the message was unclear and I mixed different issues up. Ha! It seems that I've answered myself. So, please correct me If I'm wrong. I'm going to give Kubuntu 11.4 and KDE 4.6 a whirl. Tomorrow I'm going to install it. I read that in 11.4 there's new driver than it is now so maybe it is a chance? Thank you very much! You're so helpful! I'd like to emphasize that I do appreciate your work! You rock and so does KDE! |
KDE Developer
|
That's exactly the regression in driver quality I have been talking about. In 10.04 you were using old drivers which do not support the functionality. We disable the effects. In 10.10 newer drivers are used which think they support the features ending in the mess we have When effects are off KWin is not responsible for painting the windows. That sounds like either a driver or an X server bug.
At least KWin will perform much better - no idea about the drivers. I haven't tested 11.04 yet. |
Registered Member
|
Thanks mgraesslin for your explanations, here and in your blog.
In KDE 4.6 I no longer have the problems described above. I just keep having the problem that the text of the descriptions in Present Windows is not shown, but effects works much better Now, I have a new problem and I do not think that is precisely related to 3D effects since the problem occurs with the effects disabled and with them activated the problem gets worse. The problem is that the movement (dragging) of windows on the screen is slow and are screen refresh problems since windows leave traces for a while. This is most evident when the window size is large and a high screen resolution is chosen. I tried the native and raster Qt Graphic System, occurs in both. Obviously the problem does not occur and everything is faster if you disable "Show windows content while dragging". Tested on Kubuntu 10.10 and OpenSuse 11.4, both with KDE 4.6. I will try to find any reports of this problem to see if it's a KDE or "radeon" driver problem. Thanks. PS: With the effects turned on windows do not leave traces, but dragging the window the movement is slow and not fluid. The mouse pointer moves in real time and fast but the window does not follow the movement and allways is delayed. |
Registered users: Bing [Bot], Google [Bot], Sogou [Bot]