Re: [Mesa-dev] KWin and Mesa
On Wed, 20 Apr 2011 04:32:25 +0200, Henri Verbeet hverb...@gmail.com wrote: On 19 April 2011 16:52, Martin Gräßlin mgraess...@kde.org wrote: Hi Mesa-devs, yesterday I published a rant about Mesa breaking KWin and given some comments on Phoronix Forums it seems like there is the wish for more communication between our development groups and so I want to start it. Please note that I am not subscribed to this mailing list, so please keep me in CC (I might not be able to reply this week at all). It is my wish to never have to rant about the state of Linux drivers any more and that I never have to see Mesa breaking KWin again. I think there are a couple of points here, some of them already made by others. Note that the following is mostly just how I personally see things, not necessarily what anyone else thinks. Thanks for your mail. This is really constructive and a reply in the kind of I hoped to receive. A good starting point to fix the mess we are currently in :-) First, there's the specific issue your blog post talks about. While I understand the issue, and can sympathize somewhat, I essentially think you're just wrong there. (Yeah, I can be direct too.) It's perhaps unfortunate that this change happened on a minor release, but the basic issues are that blacklisting / whitelisting drivers is just a bad idea, and you can't depend on renderer strings being stable. If you do it anyway, it's going to break, you get to keep all the pieces, and you can't blame the drivers. Actually I agree with you and all other who wrote it: it is a hack and it should not be there. It was added to make KWin at least work around the 4.5 release. As a matter of fact and that question might sound stupid, where do I find information on additional API provided by Mesa than not parsing the renderer/version string? In the response to the blog post I received replies that we should use DRI2QueryVersion. That was the first time that I heard this thing existed. Where is that documented? How can we find out about it? I seriously have never ever heard about it or read about it in any documentation I have read so far. In the more general case, I think hacking around driver bugs is about the worst way to deal with driver bugs in GL applications. In the best case you're just removing an incentive to fix the bug, but it's more likely you just end up creating fragile code or depending on the bug somehow. The problem is that at the time we release it has to work. Our users do not care about whether it is the driver or not. It just has to work. A big problem in that regard is as you noticed yourself the distributions. They do not ship updates to the drivers, so we need to make it work with the driver version out there and not with the next bug fix release. Our work would be much easier if we could just tell the users to update their drivers ;-) IMHO it's better to just direct users to the appropriate bug tracker in those cases. You'll get some flak for that, but it's worth it in the long term. Of course the best way would be to work on fixing the bug in the upstream project, but I realize that may not always be practical. We do tell the users to report the bugs upstream. I don't know if they do it, but we tell them. We cannot do much more - I personally don't want to play proxy for bugs I cannot reproduce with my hardware. I also reported the only bug I ever encountered with free drivers, unfortunately nobody ever replied to it. Note that I think distributions have some role to play here as well. I think it's just about as unreasonable to expect driver developers to test with every application as it would be to expect KWin developers to test with every possible hardware / driver combination. (And you can't say My application is more important. either. You're going to find plenty of users that would gladly have us e.g. completely break KWin to make StarCraft 2 run faster, and viceversa.) Realistically speaking we'll have to depend on users / testers testing with development versions to find bugs before releases. If nobody reports bugs that either means nobody noticed or nobody cares. An important part of what distributions are supposed to do is making sure things work well together, so I don't think it's all that unreasonable to expect them to do that kind of testing and report / fix bugs where appropriate. If it does come to the point of writing hacks (pending a proper fix) it's probably also more appropriate for a distribution to carry those than KWin. Normally distributions do not want to have specific code. Especially KDE discourages distros to create specific hacks. If I think of Kubuntu they for example would not have the manpower to create the patches and would ask me to fix it. Most packagers do not have any knowledge in this area. But it's also working now: Ubuntu includes a fix for the problem now (adding GEM again) and Fedora is at least interested in adjusting the code to make
Re: [Mesa-dev] KWin and Mesa
On Wed, 20 Apr 2011 09:34:01 -0400, Jerome Glisse j.gli...@gmail.com wrote: Your issue is right there, gnome-shell have been successful dealing with that because they target a particular mesa version and they set a lower bar for the GL feature they need. Your issue is that you want to enable feature that are using too advanced GL stuff for the opensource driver, GLSL wasn't that good before mesa 7.7 (or even 7.8 can't remember). What you should do is decide was is the lowest mesa version you are ready to support and then use that to decide what gl feature you can safely use. If you want to support debian that would more than likely mean dropping glsl. Trying to enable feature one by one is a real bad idea, again i believe here gnome-shell took the right approach. GNOME Shell was in a much better situation as they were able to develop against future releases of Mesa. Btw we do not depend on GLSL. Our important GLSL shaders are also reimplemented with an ARB Shader fallback. It should all fallback without problems nowadays. If the driver supports GLSL properly, it gets used, if it supports only ARB Shaders those will be used, if both is not supported it gets disabled. If we know the hardware has limitations we do not use the features unsupported by it. So we do what you actually ask as to do. E.g. with Debian and Mesa 7.7 it works totally fine with the ARB fallbacks (yeah I tested that ;-) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] KWin and Mesa
On Wed, 20 Apr 2011 11:59:48 -0300, Solerman Kaplon soler...@gmail.com wrote: Em 20-04-2011 09:01, Martin Gräßlin escreveu: http://lists.freedesktop.org/mailman/listinfo/mesa-dev As someone who got a user complaining about kde dragging his apps to a slowness blackhole using some intel card, I think one way to workaround such issues is making such effects more explicit. I think this mailinglist is the wrong place for such discussions. The correct one would be k...@kde.org or reporting bugs about it at bugs.kde.org. I reply here nevertheless as there is incorrect information. As a matter of fact the user would resolve the issue by upgrading the drivers - Lanczos is disabled for Intel and Mesa = 7.10 since KDE 4.6. For KDE 4.6 the recommended Mesa version is at least 7.10. Right now, the only way I can disable lanczos is using some obscure blacklist string in a hidden file. Can you please do like compiz and add a Lancozs filter effect to the kwin settings so users can easily disable that on their own? This is not correct. There is a GUI option to disable the filter since 4.6 and the blacklist has been removed from master some weeks ago. Make sure Blur (which is already there) gets really disabled when I uncheck it. Thanks in advance. For new users, maybe shipping with those effects disabled by default might be a good plan. We consider both blur and lanczos as an important part of our user experience and therefore enable it by default for users with supported hardware. It does not get enabled on hardware which does not support these shaders in a satisfying way. Cheers Martin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] KWin and Mesa
of KDE and Mesa. Anyway even if I were able to follow the upstream development it would not help much. The combinations of hardware, driver, mesa, kernel and distribution are way too high that our team can ensure that it does not break. This is something only you can ensure. I don't know if you are aware of it, but our latest version of KWin is currently used by users from Mesa 7.7 to Mesa 7.11. Our users are hitting bugs you fixed more than a year ago and we cannot just ignore our users and tell them to compile the latest Mesa version. Yes there are hacks in KWin - one of the hacks backfired last week, but this is the reason why we have hacks. We need to support yesterdays, todays and tomorrows Mesa versions. If we needed a hack to workaround an issue in an old version or KWin would crash, nobody is helped if we contact you and you tell us that the bug is fixed. Please understand that our users have the drivers the distributions give them, it is not under our control. We have developed a very complex system to ensure that our users get the best possible experience. Due to the problems we had with 4.5 and Mesa announcing support for features not supported by the chip (consider emulating GLSL in software - great for games deadly for compositors) Fredrik developed an elaborated system to detect what chipset is installed in the system and enabling features based on what the chipset really supports instead of listening to what Mesa tells us. As far as I understood you recently changed the way how the renderer and version string looks like. This means that you completely broke that system. After all that had been said about the 4.5 release I was sure that you know what KWin reads from your announced strings. Now it might be that we should not parse this information and of course you are right with saying so, but you know what Linus would answer? Never break your userspace! This is what just is happening. Now we are lucky and there is time to adjust our code base till our next major release, but again we need to at least support both Mesa 7.10 and 7.11 in one code base. Kubuntu and OpenSUSE users (both using Mesa 7.10) will upgrade to 4.7 as soon as it will be released and Kubuntu 11.10 will be 4.7 with Mesa 7.10. I think you get the problem we are in. We cannot just remove the detection code due to the experience we had with 4.5 and due to the fact that we want to give the users a good experience. If the hardware does not support shaders the CPU is most likely not powerful enough to do useful emulation. Assumptions which are correct for a game are completely wrong for a compositor. The compositor may not cause high CPU usage, the compositor may not block the system. It is a background service which just has to work and should never be visible to the user. If the user sees KWin in top something is badly wrong. So we have no other choice than to parse the renderer information as we cannot rely on the extension announced. The ideal world is one thing, but the reality looks different. I hope you better understand now my position and I hope we can both work on better collaboration in future. I still have the plan to submit our complete compositor and all effects as a set of piglit tests but we still need some refactoring and I don't know whether it is possible to take 60 kSLOC C++ code as a piglit test. Please try to get your prioritize right. It is great if the wine developers have the time and manpower to work together with you, but please also think about that others might not have the time. Please consider if it is more important to keep compatibility for an important downstream than to support some more games. Think about what you can do to ensure that I never have to notice about important changes in Upstream Mesa from upset bugreports. The only thing what we need is stability: the drivers should not break KWin. That's all I'm asking for. Let's work together on a better composited experience on X11. Cheers Martin Gräßlin KWin Maintainer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
