Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

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

  • #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


            • #46
              Originally posted by kayosiii View Post
              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.
              Yeah, that's what you have to do - fork a new process to run quick checks, handle sigaborts and disable the 3d graphics if there is a crash. Here is the related KDE code: https://projects.kde.org/projects/kd...opengltest.cpp

              The downside is that you have to do this during application startup, or booting, which isn't very nice for performance. There's not any other option that works reliably, though.

              Comment


              • #47
                Originally posted by marek View Post
                They didn't fuck up at all. The Intel devs only changed the renderer string. It's a valid change, a normal one, it may happen from time to time and apps shouldn't rely on it. On the other hand, detecting KMS/GEM/DRI2 via some string in OpenGL is clearly a hack. There are better ways of detecting those than some random string that happened to contain "GEM" by luck. (I am surprised too that someone parses that string.)

                Anyway, the fact the driver devs haven't tested it is, of course, their fault. But the real problem lies in the Kwin code, Martin has even admitted that with the code snippet in his blog post. It's pretty clear that hacks like that would cause breakage sooner or later.
                wrong, they (intel devs) fucked up major way. You don't change something like that in a point release. You just don't.

                Comment


                • #48
                  So, in an effort to promote communication he posted to the mesa dev list

                  The responses basically came back as:

                  1. Your email is too long to read
                  2. Quit whining
                  3. We don't care if we break KDE
                  4. If you're having so many problems with Mesa, maybe you should just disable all compositing on our drivers and only work with the proprietary drivers.

                  So, yeah. We're going to keep seeing this kind of stuff every 12 months, most likely.

                  I wish open source graphics could get better than this... Maybe next year.

                  Comment


                  • #49
                    Originally posted by energyman View Post
                    wrong, they (intel devs) fucked up major way. You don't change something like that in a point release. You just don't.
                    Yeah, there's absolutely NO REASON why this change needed to be done in a point release and as we can see a good reason not to do it.

                    That said, it's been pointed out that the upcoming Fedora release will be running 7.11 which IS a major release, and I do think they have every right to change the strings there. So KDE would still need to be fixed, it just shouldn't need to happen for Natty.

                    Comment


                    • #50
                      Originally posted by pingufunkybeat View Post
                      With KDE 4.5, KWin made changes which broke things on Mesa drivers and were (rightly) criticised for not testing with open drivers. They said that they trusted the drivers about the functionality they advertised, but didn't implement.
                      I haven't read the whole thread yet but as far as I can remember it wasn't that way.
                      IIRC KWin did not change anything in 4.5 which caused problems. Actually free drivers _started_ to advertise features as implemented while they weren't. Martin once pointed out that 4.4 et al. would also not work that well with the new drivers as those misadvertise features. Only that KWin got most of the blame and even for bad communciation ... [1]

                      [1] I wonder if it is good communication to set flags specified in a standard to advertise features ,that are in fact not working right. And yeah I know of the unfortunate situation that some tools require OpenGL X.Y while actually onle few features are really required. I just think that the blame was not fairly distributed.

                      Comment

                      Working...
                      X