Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by pingufunkybeat View Post
    But this time, it's not KDE who released a new version, it was Intel, and they didn't check if it works. Now KDE is facing the possibility that compositing will be broken on Ubuntu for the next 6 months.
    Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?

    Comment


    • #32
      Originally posted by locovaca View Post
      Why is it Intel's responsibility to test KDE's code out with their driver?
      Because there is no point in having a driver which does not work with widely used software. We are not talking about a random 3D application here but about one of the major Linux desktops. Testing their driver on the major Linux desktops is the least Intel can do.

      Comment


      • #33
        Originally posted by locovaca View Post
        Why is it Intel's responsibility to test KDE's code out with their driver? What other packages should Intel be testing against?
        Compiz and Mutter. And any other application which is used daily by tens of millions of people.

        I mean, if people expect KDE guys to test several dozen drivers (and I do), then I'd expect a driver dev to have a quick check whether he broke the second most widely used window manager under Linux.

        Comment


        • #34
          P.S. It's still wrong to rely on the renderer string, and I still have no better solution for enabling basic functionality on software people expect to just work.

          Comment


          • #35
            Originally posted by pingufunkybeat View Post
            Marek, how would you test correctly if a driver provides appropriate functionality?

            It is known since the last KWin fiasco that you can't trust the advertised functionality,
            When some Kwin dev (maybe Martin again?) claimed that, no open driver developer knew about broken advertised functionality. We thought everything was alright, everything worked fine for us. Most games ran beautifully. The drivers do NOT claim to support things they do not support. As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.

            Moreover, the NVIDIA OpenGL implementation is far from being compliant, so if something works on NVIDIA, it pretty much means it might not work anywhere else. I *like* proprietary drivers, but relying solely on NVIDIA ones might lead to frustration as you can see in various Martin's blog posts. Unlike NVIDIA, both Catalyst and Mesa try to follow the OpenGL specification to the letter, even though the spec is sometimes self-contradictory or doesn't make sense.
            Further reading on the subject (a little bit more technical): http://www.g-truc.net/post-0348.html

            Originally posted by pingufunkybeat View Post
            and checking for direct rendering is also a hack which doesn't even work anymore. Blacklists caused their own set of problems, and if there is no check, KWin will crash all the time, like 4.5 did.

            What is the correct way to check this?
            The best way is to communicate and do the job right. Linux will never work if developers ignore each other. The Kwin devs should assume everything works and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.

            The worst scenarios are:
            - Reverting to an older version without telling anyone and hoping the problem will be fixed in the next version (it won't).
            - Blacklisting the software without telling anyone (again, it won't get fixed until either a developer runs into it or a user reports it). And don't forget to make a blog post about it to piss off everybody else.

            As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.

            Comment


            • #36
              Originally posted by marek View Post
              As far as I remember, he did not prove that some functionality had really been broken. You can say that e.g. FBOs or even drivers are broken, but no one will listen to you if you don't say what's exactly broken. There is nothing to talk about without the prove.
              I agree that communication is important and desirable, but if the drivers crash, then surely something is wrong. Drivers should never crash, and this is what was happening with KWin 4.5, using advertised functionality. On all drivers, not just Intel, it was a Mesa bug.

              Regardless of whether it was reported correctly to the Mesa devs, or tested at the right time before releasing, which is a different issue.

              As for how detect GEM/KMS: Check the list of loaded kernel modules and talk to them via sysfs or something. But keep in mind that the OpenGL driver has nothing to do with it.
              But some people don't use modules. And DRI2 is only used by open drivers, as is exposing stuff through sysfs. Perhaps it's better than grepping the renderer string, but it's bound to be considerably more complicated and is also bound to change between driver versions, leading to complex logic.

              I don't know of a single, reliable way of detecting what the driver can actually accelerate reliably. Ideally, they would all accelerate everything reliably, but unfortunately this is not likely to be the case soon.

              Comment


              • #37
                Originally posted by marek View Post
                The best way is to communicate and do the job right.
                Agreed, but this works both ways. In this case, it seems like the Intel driver developers should have gotten this news out to people using the driver.

                The Kwin devs should assume everything works
                That's what they did for 4.5, and it didn't turn out very well.

                and if it doesn't, they should immediately inform us, like report a bug, send an email to the mailing list, drop by on IRC, etc. Distribution vendors should make sure that whatever they ship works well. If it doesn't, they should talk to developers immediately again, so that things get resolved in a timely manner.
                Definitely. However, often the response is "fixed in latest git" which doesn't really help the KDE devs much. They have to work with older drivers that are actually being shipped in distributions, or people complain. And I don't think it's reasonable to force the distros to always ship the latest git drivers either.

                I think everyone can agree that they way KDE is parsing that string is hacky, but I think they have a point complaining here. Why would Intel change the userspace API (even if it's a hack, they know people are using it) like that in a point release which is supposed to be bugfixes only? Or at least that's what i thought they were meant to be. Just wait for 7.11 to come out. There also wouldn't have been an issue if the change hadn't occurred right before an Ubuntu release but right after a KDE release - presumably they were trying to sneak some fixes in for Ubuntu, and managed to completely break the other desktop as a result. It doesn't really matter who's to blame at that point, all the user knows is they updated a package and everything broke. That shouldn't happen in a point release, IMHO.

                Comment


                • #38
                  Originally posted by marek View Post
                  Most games ran beautifully.
                  Hell of test you did there. Especially when it comes to Linux.
                  Maybe we should all ditch desktop environments and find a way to run apps from the CounterStrike console.

                  PS: running radeon here and all I see is degraded performance with every Mesa / Xorg / kernel upgrade. Both gnome3 and kde.

                  Comment


                  • #39
                    Originally posted by roentgen View Post
                    Hell of test you did there. Especially when it comes to Linux.
                    Maybe we should all ditch desktop environments and find a way to run apps from the CounterStrike console.

                    PS: running radeon here and all I see is degraded performance with every Mesa / Xorg / kernel upgrade. Both gnome3 and kde.
                    Must be the test we added for noticing if the user has posted dumb stupid shit to phoronix and slowing his machine down.

                    Dave.

                    Comment


                    • #40
                      Originally posted by airlied View Post
                      Must be the test we added for noticing if the user has posted dumb stupid shit to phoronix and slowing his machine down.

                      Dave.
                      hahahaha.

                      Still, wouldn't you agree that a proper testing procedure before releasing a "stable" release would be: 1. launch Gnome + compiz, 2. launch Gnome + Mutter, 3. launch KDE, and test to make sure all continue to work? And if not, email the project in question to try to figure out why a stable release broke something?

                      I think much of the frustration here is coming from the fact that a project like Compiz or KDE are used by about 50% of users. Even the most popular game is probably in single digits. So it seems like more attention should be given to one rather than the other, and it seems like the opposite is actually true.

                      Comment


                      • #41
                        Not everybody will notice if kde disables an effect. Basically there is a skip function check override, does that work or not? For fglrx you usually have to use it when you want to start with effects enabled with kde 4.4.5. Somehow a few times alt+shift+f12 enables it too... You can use kde, just with fewer effects by default, that may not be nice, but at least you see something. When i think about the new gnome shell then this can be completely differnet there - maybe gnome shell will enforce working 3d drivers...

                        Comment


                        • #42
                          Ideally it should be possible to query the drivers for the functionality that it supports. If I understand correctly the Driver devs report features that are not there essentially to get games that otherwise wouldn't run (for wine mostly I assume).
                          The best solution I can think of is to have a flag that says - "no I really need to know which features are supported, don't bullshit me". that can be passed with your query.

                          Comment


                          • #43
                            Originally posted by kayosiii View Post
                            Ideally it should be possible to query the drivers for the functionality that it supports. If I understand correctly the Driver devs report features that are not there essentially to get games that otherwise wouldn't run (for wine mostly I assume).
                            The best solution I can think of is to have a flag that says - "no I really need to know which features are supported, don't bullshit me". that can be passed with your query.
                            The drivers don't advertise things they don't support, but GL is a huge API and there are often corner cases that are not well tested or certain combinations of features that are not supported due to limitations in the driver or hardware.

                            Comment


                            • #44
                              Originally posted by kayosiii View Post
                              Ideally it should be possible to query the drivers for the functionality that it supports. If I understand correctly the Driver devs report features that are not there essentially to get games that otherwise wouldn't run (for wine mostly I assume).
                              The best solution I can think of is to have a flag that says - "no I really need to know which features are supported, don't bullshit me". that can be passed with your query.
                              Some of the feature tests would actually cause the driver to crash with older versions, which means you can't test for them unless you already know you have a good version of the driver present.

                              Mesa devs solution to this is just to require everyone to have new drivers present, but that's not realistic or reasonable for a desktop environment. Therefore you get hacks like this where they end up parsing strings.

                              Comment


                              • #45
                                Some of the feature tests would actually cause the driver to crash with older versions, which means you can't test for them unless you already know you have a good version of the driver present.
                                Wait are you sure... Feature tests usually mean running a small program and seeing if it works in order to find out whether certain features are enabled which shouldn't be the same as querying a driver to find out what features it supports.

                                Comment

                                Working...
                                X