Announcement

Collapse
No announcement yet.

Martin Takes His Mesa Issues To The List

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

  • #16
    Originally posted by Xilanaz View Post
    None the less distributions ship with these (in previous post mentioned) experimental drivers installed by default and users expect a working good looking DE.
    Then the issue is the distribution, not the DE. If a distribution is going to throw crap together without testing it (a development model wholeheartedly endorsed by some distributions for sure), that needs to be on the distribution. KDE is not a distribution, no more than Mesa is a composting desktop environment.

    Comment


    • #17
      Indeed, it seems like a consensus is attainable:

      Mesa devs: Keep doing what you're doing, but run some piglit tests for KDE now and then to make sure you aren't inadvertently breaking something they rely upon (assuming that they rely upon features that are within scope of the OpenGL standard they're targeting).

      Kwin devs: Take out the whitelisting/blacklisting stuff, and check for extension availability using the standard GL calls. You can also parse the first few characters of the version string because they are required by the standard to report the core GL version there; it's an easy out if it's not >= what you need. But don't rely on the rest of the version string. Instead, just make your best effort to use features that work with reasonably modern versions of Mesa on most drivers, and report bugs when you find that something advertised doesn't work.

      Distributions that ship KDE4: Before you release, do a fresh install of your distro, using your distro's version of Mesa, and boot up KDE. Do not install the binary drivers. (If you don't have a card that works with Mesa, buy one, or find a reliable community member who has one and can test on your behalf.) Assuming that you have a working, hardware-accelerated mesa stack: Do you get compositing? No? Then: either figure out whether to upgrade or downgrade either KDE or Mesa to make it work, or post on the ML that you need to make Mesa version XYZ work with KDE version XYZ, and ask for an approach or a patch. The fact that distros don't want to provide or request workarounds is irrelevant: the fact remains that it's their software distribution and the responsibility for getting it working is ultimately on them, at the end of the day.

      So KDE and Mesa devs will make their best effort to be compatible, but due to the lack of manpower neither side can afford to manually test the software. They must both operate under the assumption that >90% of users will never compile their own version of the software manually, and those who do so are accepting the onus of either reporting bugs or fixing things. Then the distribution must realize that they need to test their software as much as possible, because it's hardly a foregone conclusion that slapping a bunch of packages together will "just work" -- that's why distributions exist!

      The upstreams here are doing things mostly right, and users who expect all upstream code from all projects to integrate flawlessly with no hacks are living a pipe dream. Here I say "users" to mean both individuals compiling stuff from source, as well as distributions. The difference is that, we assume, distributions contribute quite a lot of testing, integration and hacking to the equation, to smooth out any wrinkles encountered from upstream. This might raise the bar relative to what some distributions provide, but clearly if you look at RHEL or Debian or SUSE, this kind of rigorous testing is known to happen with some existing distros. And when it doesn't happen, the frequency of bug encounters is much higher across the board, not just in Mesa and KDE.

      If we want to improve the out of the box experience for non-technical end-users (and I think everyone agrees this is a good thing), the main responsibility is on distros. Distros fill an essential, indispensable role in converting "raw" free/open source software into a polished product. We should all recognize what a great contribution they make, and encourage the distros that don't live up to the quality bar to improve.

      Comment


      • #18
        The Mesa developers said that they don't consider KDE to be one of its most important targets. That makes me wonder: if the first or second most-used X11 window manager isn't one of their most important targets, then who is? They don't say.

        Comment


        • #19
          Originally posted by allquixotic View Post
          Indeed, it seems like a consensus is attainable:

          Mesa devs: Keep doing what you're doing, but run some piglit tests for KDE now and then to make sure you aren't inadvertently breaking something they rely upon (assuming that they rely upon features that are within scope of the OpenGL standard they're targeting).

          Kwin devs: Take out the whitelisting/blacklisting stuff, and check for extension availability using the standard GL calls. You can also parse the first few characters of the version string because they are required by the standard to report the core GL version there; it's an easy out if it's not >= what you need. But don't rely on the rest of the version string. Instead, just make your best effort to use features that work with reasonably modern versions of Mesa on most drivers, and report bugs when you find that something advertised doesn't work.
          This is not possible. A few months ago, the Kwin developers were complaining about another major FUBAR situation with Mesa, but I think it was related to the radeon drivers. The drivers would report that they supported various extensions but didn't and would subsequently break Kwin when it tried to use those extensions. Hence, the crude black/white lists. I also seem to remember that there were situations where even checking for capabilities could crash some drivers.
          They simply can't check the driver for extension support because the open-source drivers frequently lie about what is implemented.

          Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.

          Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?

          Open-source developers, stop changing stuff just to change it. It breaks other code.

          Comment


          • #20
            Originally posted by jbrown96 View Post
            Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.

            Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?
            Because it is a lot more useful for a lot of people the way it is now. Please consider thinking before posting dumb shit. Try to get some clue on what you are talking about and then come back.

            Comment


            • #21
              Originally posted by TheBlackCat View Post
              The Mesa developers said that they don't consider KDE to be one of its most important targets. That makes me wonder: if the first or second most-used X11 window manager isn't one of their most important targets, then who is? They don't say.
              They're simply morons. Some of them are paid by Red Hat and it seems Red Hat doesn't care about desktops at all.

              Comment


              • #22
                The best and most practical solution would be letting KWin do a series of small tests when noticing the OS freshly installed, an update to drivers(other relevant software) or device change.
                (Default on) So KWin can send automated bug reports and inform the user.

                (Why is everyone having such a hard time figuring out what to do in a case like this?)

                Comment


                • #23
                  More tests on Mesa wouldn't hurt either.
                  (Hint: Including starting multiple apps that use the card to see if they mess up.)

                  Comment


                  • #24
                    Originally posted by Xilanaz View Post
                    What I did find a bit sad in the reply's to Martin is that one person mentioned "Also as said half a year ago, blacklisting features in kwin based on some renderer string is a _very_ bad idea. " to me means they at least knew about it ? So they also knew that changing that string would cause problems ? They could have contacted Kwin dev about the upcoming change ?
                    The Mesa developers did warn Martin that blackclisting would not work in the long term, six months ago. As expected, it broke; this is not Mesa's fault.

                    In any case, the result of glGetString(GL_RENDERER) is *not* part of the ABI and should not be relied upon (it *will* change from version to version). The Mesa devs have shouted this time and time again, yet some people still manage to get it wrong.

                    Comment


                    • #25
                      Originally posted by jbrown96 View Post
                      A few months ago, the Kwin developers were complaining about another major FUBAR situation with Mesa, but I think it was related to the radeon drivers.
                      No. because KDE don't test there Desktop with ATI. Read the Email and Marek say that the driver don't export EXT that the not Support.

                      Originally posted by jbrown96 View Post
                      Martin goes on to talk about how NVIDIA doesn't change their renderer line. Why is this such a difficult concept to grasp?
                      Who cares?

                      Originally posted by jbrown96 View Post
                      Open-source developers, stop changing stuff just to change it. It breaks other code.
                      If KDE want to prevent regressions why not add some Piglit tests?

                      Comment


                      • #26
                        Originally posted by plonoma View Post
                        More tests on Mesa wouldn't hurt either.
                        (Hint: Including starting multiple apps that use the card to see if they mess up.)
                        Mesa has an Test Suit but there are no tests for KDE. Maybe because none from KWin want to make an piglit test.

                        Comment


                        • #27
                          Originally posted by kraftman View Post
                          They're simply morons. Some of them are paid by Red Hat and it seems Red Hat doesn't care about desktops at all.
                          I guess they don't care about kde (and I don't blame 'em).
                          Perhaps one of the Novell mesa developers can test kde and make sure it works for suse distros.

                          Comment


                          • #28
                            Originally posted by jbrown96 View Post
                            Honestly, I don't get how this is the responsibility of anyone but Intel/Mesa. If you look at the change to the renderer line, it wasn't done for any purpose. It didn't change vocabulary to convey a different feature-set. All they did was remove "GEM" from the renderer line. Why Intel? It doesn't make any sense. It was a careless change that served no useful purpose.

                            Open-source developers, stop changing stuff just to change it. It breaks other code.
                            Maybe do a little bit of research before you start spouting off when you have absolutely no idea what you're saying?

                            http://lists.freedesktop.org/archive...ch/006321.html
                            http://cgit.freedesktop.org/mesa/mes...fe3e505674705a
                            http://cgit.freedesktop.org/mesa/mes...2d6991a7385b59

                            Comment


                            • #29
                              Originally posted by not.sure View Post
                              I guess they don't care about kde (and I don't blame 'em).
                              Perhaps one of the Novell mesa developers can test kde and make sure it works for suse distros.
                              This is probably true and this makes me thinking if I shouldn't just trow my card away, because I don't care about gnome at all. If open source drivers I'm using are made for gnome they're useless for me. I didn't have very good experience with nvidia blobs, but at least nvidia cares about KDE and I noticed most of the nvidia users chooses KDE. If os drivers won't be playing good with KDE I'll simply switch to something better. I guess many people will do the same.

                              Comment


                              • #30
                                I think this is a distribution problem

                                I assume Martin has already updated the KWin compositing whitelist to include the new Intel driver. So biggest problem here seems to be that Ubuntu (and perhaps other distributions) are unlikely to provide the KDE update in a timely manner?

                                Also, drivers lying about their capabilities should be regarded as a critical driver bug. I'm not sure that it's reasonable to expect a window manager to handle that gracefully. Again I assume that driver bug was fixed fairly quick, and that what made it a big problem was that Ubuntu (and perhaps other distributions) were unlikely to provide the driver update in a timely manner.

                                To me, these are just more reasons to prefere rolling release distributions. They get updates and fixes to their users as soon as possible.

                                Comment

                                Working...
                                X