Announcement

Collapse
No announcement yet.

Intel Mesa Gives Problems With KDE's KWin, Again

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

  • #51
    smitty3268 and the E-Mail sounds like "Do it like we/I want" from Martin Grlin. I bet this is the reason why he get this type answers.

    > http://lists.freedesktop.org/archive...il/006870.html

    Comment


    • #52
      Originally posted by mat69 View Post
      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.

      Originally posted by mat69 View Post
      Only that KWin got most of the blame and even for bad communciation ... [1]
      Maybe because of
      Originally posted by Martin Grlin
      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)
      The most big changes like this are discussed on the Mailing list.

      They don't care about Mesa and they don't test there Stuff on the Free Drivers. Its Sounds like he/kwin test only on the Nvidia Blob.

      Comment


      • #53
        Originally posted by Nille View Post
        smitty3268 and the E-Mail sounds like "Do it like we/I want" from Martin Grlin. I bet this is the reason why he get this type answers.

        > http://lists.freedesktop.org/archive...il/006870.html
        I agree that certain stuff from Martin needs to change. But instead of taking the opportunity to discuss that with him the Mesa devs chose to flame him, thereby ensuring that nothing changes and we will run into the same problems again.

        Mesa devs are not solely to blame, but neither are they blameless. Currently both sides are acting like idiots, and when 1 makes at least an effort at conciliation it's disappointing when that effort isn't returned.

        Comment


        • #54
          Just to be clear about what i think needs to happen:

          Martin needs to stop his stupid "i can't be bothered to test current Mesa code" argument.

          Mesa devs need to stop their stupid "i can't be bothered to test KDE" argument.

          Both sides need to stop their stupid "everytime something goes wrong start shouting about how much the other side sucks" behavior.

          These problems are going to continue until both sides get it together and actually give a **** about their users. Right now they both seem more interested in scoring points.

          Comment


          • #55
            Originally posted by mat69 View Post
            [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.
            This issue comes up every few months. The core problem here is that the KDE devs were writing new code which used OpenGL features that were just being implemented in the open drivers. Nothing wrong with that in principle but it requires fairly close communication between app and driver developers so everyone understands what should and should not work.

            Most of those issues are in the past now, but one part of the problem will remain more or less forever -- the fact that OpenGL 2.x came out after DX9 hardware was designed but doesn't quite match the DX9 requirements. As a consequence of this, there are multiple generations of cards which can run GL 2.x well enough that users want it enabled (ie want the features advertised) but which can not provide 100% support and never will.

            The choices are either to disable GL 2.x features completely (thereby costing users the ability to run a large number of interesting and useful apps) or enable the features and recognize that they are always going to be "implementation errors" when running on DX9 hardware because the hardware doesn't support everything that GL 2.x requires.

            Comment


            • #56
              Like I said I think the best way would be to pass a flag when asking about advertised features that tells the driver to only say yes if the feature is fully implemented and stable. That way a client could ask for only features that are done and really implemented.

              Comment


              • #57
                Originally posted by mat69 View Post
                Actually free drivers _started_ to advertise features as implemented while they weren't.
                I couldn't disagree more. The features were implemented as much as they could be on the given piece of hardware. GLSL is not C. An arbitrary piece of code in GLSL might not work everywhere. That's the reality. Just pay attention to your code and it will pay off.

                As for the discussion on the ML, it proves that nobody has the time to test his software with someone else's software. Most people are unpaid and simply don't care. (what would you choose: hacking some drivers or kwin for free, or checking out the chick who lives next door, or maybe playing in a rock band and have some fun?)

                Comment


                • #58
                  Originally posted by marek View Post
                  I couldn't disagree more. The features were implemented as much as they could be on the given piece of hardware. GLSL is not C. An arbitrary piece of code in GLSL might not work everywhere. That's the reality. Just pay attention to your code and it will pay off.

                  As for the discussion on the ML, it proves that nobody has the time to test his software with someone else's software. Most people are unpaid and simply don't care. (what would you choose: hacking some drivers or kwin for free, or checking out the chick who lives next door, or maybe playing in a rock band and have some fun?)
                  I have to admit that I lack the knowledge in this regard and was posting what I remembered or thought to remember.

                  In any case I think we can agree that blogs for sure aren't the correct medium to raise issues. I think they are a good way to inform others (i.e. not the affected devs) of it, but informing should imo ideally not contain finger pointing at all. Still the situation for the users is bad and that should improve one way or the other.

                  Comment


                  • #59
                    Martin's email to mesa-dev really doesn't paint him in a good light. Interpersonal skills are of utmost important to a project manager and he displays close to none. Plus, his racist remark was very ill-conceived.

                    In any case, the solution is simple:
                    (a) write piglit tests to cover kwin functionality
                    (b) establish minimum version requirements (e.g. kwin 4.7 requires mesa 7.11)

                    Ranting and panting won't get us anywhere.

                    Comment


                    • #60
                      Originally posted by BlackStar View Post
                      Martin's email to mesa-dev really doesn't paint him in a good light. Interpersonal skills are of utmost important to a project manager and he displays close to none. Plus, his racist remark was very ill-conceived.

                      In any case, the solution is simple:
                      (a) write piglit tests to cover kwin functionality
                      (b) establish minimum version requirements (e.g. kwin 4.7 requires mesa 7.11)

                      Ranting and panting won't get us anywhere.
                      What kind of racist remark are you talking of?

                      Imho his mail is indeed way too long and might apear arrogant instead of solution oriented. I doubt that devs who themselves have to cope with rare spare time they can invest in their projects are willing to read long rants in this regard.

                      Comment

                      Working...
                      X