Announcement

Collapse
No announcement yet.

Mir Support Not Merged For Mesa 9.2

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

  • #21
    Originally posted by jrch2k8 View Post
    well to be honest i doubt this patches will be accepted and is probable canonical got the idea already and won't bother anymore in trying

    1.) Mir is a single distro solution that im not sure mesa dev be eager to upstream
    2.) Nobody except canonical uses Mir, so the review process will be hard since mesa devs won't install Mir to test the patches
    3.) Who is going to maintain it? if that is not well defined no one will step to it fix it if it gets broken
    4.) Canonical send a patches already to mesa mailing list and those went straight to /dev/null

    Btw Michael is been reported Mir/Xmir is broken in radeon and nouveau drivers, maybe you should check it out as far as i care to look it only works on intel
    I've got to defend Canonical on point 3, here. We've seen several unmaintained drivers (DRI1 drivers had plenty of time to rotten before they reaped them) and trackers (DirectX 10 and 11) on mesa. The first case I recognize they *were* maintained when the patches got accepted (they were probably the most advanced drivers on mesa back then), but DirectX trackers for Gallium were always kind of just an experiment. It would have been good to see them maintained and in use, specially for WINE I think.
    On the other points I agree, provided the (likely) policy of not accepting distro specific patches.

    XMir *kind of* works on my R600. It's slow as hell (seriously slow, far slower than software rasterizer on an older computer with X.org), but except for Mir's cursor freaking the hell out of me, it worked. The fix for the extra cursor was reported to be in the works yesterday, and was tagged as critical. I'm not sure how should I report the performance problems, or how to give measured, maybe reproducible, numbers on the performance that reflect what I'm seeing. I'll look into it, but if someone can give me directions, they will be welcomed.

    Originally posted by boast View Post
    So it is: Open source software... where you can do whatever you want (as long as we approve)?
    No, it is open source software, where you can do whatever you want as long as you don't infringe any license, but you must face the consequences of your choices and stop blaming others for your lack of conscience, and respect that some people might not approve. Nobody is banning them from doing whatever they want, but you can not ban us from pointing out they're being douchebags. And should respect our opinion, and if you want to prove we are wrong, then do it, prove it based on any technical fact. As I stated several times, I'm open to change my mind on the issue, given a reason to. Right now, I gave it a shot to test Xubuntu on top of XMir, and it gave poor performance, just as expected, and an ugly and confusing glitch with the Mir cursor being there at the same time the X.org cursor, out of sync. So, I stand in the same position about running a desktop on XMir. About Mir, I'm still waiting for a reason not to just use Wayland, or at least fork it in a compatible way (i.e., reap out all thing they do not want, while keeping intact what they will, in other words, using a subset of it).

    Comment


    • #22
      Michael: Nobody thinks any upstream project will accept Mir patches. So don't write news when they are rejected, write news when they are accepted... :P

      Comment


      • #23
        Here goes typical FUD:
        """
        well to be honest i doubt this patches will be accepted and is probable canonical got the idea already and won't bother anymore in trying

        1.) Mir is a single distro solution that im not sure mesa dev be eager to upstream
        2.) Nobody except canonical uses Mir, so the review process will be hard since mesa devs won't install Mir to test the patches
        3.) Who is going to maintain it? if that is not well defined no one will step to it fix it if it gets broken
        4.) Canonical send a patches already to mesa mailing list and those went straight to /dev/null
        """

        1) Ubuntu is single BIGGEST Linux distro. Lets talk about REAL Linux users affected. Shall we? (Or maybe for some unfanthomable reason will we start to exclude Linux users?)

        2) You suggest that no Mesa folk use Ubuntu as development environment? ITS NOT CANONICAL WHO ONLY USE UBUNTU. Its large distro. Perfectly capable to host development of kernel/mesa/xorg (for now). After Mir will be only thing maintained by Canonical, than devs will need to compile & install kernel/mesa/xorg/wayland on their own. But that IS WHAT THEY DO NOW. Since developing always involve working on bleeding edge.

        3) Are you suggesting that Canonical will push CRITICALLY IMPORTANT code for THEIR MIR EFFORT, and then will not care about bugs in that code? That they will then go and will stop maintining that code upstream, and will only provide downstream fixes? Right, because Canonicall devs all dream about wasting their time and effort on work that will be unneeded by anyone.

        4) That only show problem within MESA development community. Is Mesa ONLY for specific distros? NO. (Go look at your 1) ) So why they refuse to work with people who have certain requirements for Mesa, and work with others who have very similar requirements? Technical reasons? (Beyound Your FUD)

        Comment


        • #24
          Originally posted by TAXI View Post
          Michael: Nobody thinks any upstream project will accept Mir patches. So don't write news when they are rejected, write news when they are accepted... :P
          Current news is about:

          "Canonical have NO ready code for merging in Mesa9.2"

          Mesa maintainers can not reject code that is not there
          (And rejecting RFC code happen all the time. That is nothing special. In fact its purpose of RFC...)

          Comment


          • #25
            Originally posted by przemoli View Post
            1) Ubuntu is single BIGGEST Linux distro. Lets talk about REAL Linux users affected. Shall we? (Or maybe for some unfanthomable reason will we start to exclude Linux users?)
            I don't see how it makes any difference.
            It is quite obvious why open source project do not accept distro specific patches :
            - if they do, the project knows that at some point in time, the distro specific code will stop being maintained by the distribution developers and the burden will fall on the usually overwhelmed by work project developers.
            - By keeping distro-specific code out, they make sure that these patches will still being maintained by the distribution developers.

            It is as simple as that. And as long as Mir is Ubuntu-only, whatever the size of Ubuntu market share, any patch for Mir will be considered distro-specific and quite probably rejected.
            Canonical wanted to go their own way, they have to assume the consequences themselves. As long as they do, that's not a problem to anyone and no one is to blame. If they don't, they should not complain to the Mesa team, and so do you.
            It's obviously quite different when you actually participate to the project. You can then influence its directions. Red Hat actually does this rather well.
            But Canonical isn't basically participating to any projects but their own, so they can just blame themselves.

            Originally posted by przemoli View Post
            4) That only show problem within MESA development community. Is Mesa ONLY for specific distros? NO. (Go look at your 1) ) So why they refuse to work with people who have certain requirements for Mesa, and work with others who have very similar requirements? Technical reasons? (Beyound Your FUD)
            See above.
            And yes, I absolutely believe that if Canonical wanted to have the Mir-specific code into upstream mesa, it's definitely to have it supported by the mesa team in the end, instead of doing it themselves. Otherwise, what would be the point in pushing it upstream?

            Comment


            • #26
              Originally posted by przemoli View Post
              Here goes typical FUD:
              """
              well to be honest i doubt this patches will be accepted and is probable canonical got the idea already and won't bother anymore in trying

              1.) Mir is a single distro solution that im not sure mesa dev be eager to upstream
              2.) Nobody except canonical uses Mir, so the review process will be hard since mesa devs won't install Mir to test the patches
              3.) Who is going to maintain it? if that is not well defined no one will step to it fix it if it gets broken
              4.) Canonical send a patches already to mesa mailing list and those went straight to /dev/null
              """

              1) Ubuntu is single BIGGEST Linux distro. Lets talk about REAL Linux users affected. Shall we? (Or maybe for some unfanthomable reason will we start to exclude Linux users?)

              2) You suggest that no Mesa folk use Ubuntu as development environment? ITS NOT CANONICAL WHO ONLY USE UBUNTU. Its large distro. Perfectly capable to host development of kernel/mesa/xorg (for now). After Mir will be only thing maintained by Canonical, than devs will need to compile & install kernel/mesa/xorg/wayland on their own. But that IS WHAT THEY DO NOW. Since developing always involve working on bleeding edge.

              3) Are you suggesting that Canonical will push CRITICALLY IMPORTANT code for THEIR MIR EFFORT, and then will not care about bugs in that code? That they will then go and will stop maintining that code upstream, and will only provide downstream fixes? Right, because Canonicall devs all dream about wasting their time and effort on work that will be unneeded by anyone.

              4) That only show problem within MESA development community. Is Mesa ONLY for specific distros? NO. (Go look at your 1) ) So why they refuse to work with people who have certain requirements for Mesa, and work with others who have very similar requirements? Technical reasons? (Beyound Your FUD)
              1) Anything to back that up? I see Canonical making red numbers only while Red Hat gets the money. What are REAL Linux users? Desktop users only? Why are server administrators, mobile phone users and so on not real? But after all the size of the distribution doesn't make it more than one, so the single distro argument stays valid. As rvdboom already told: Why does Canonical have to have it upstream when they are the only distribution using it and when they want to maintain it?

              2) Yes, I don't think mesa devs will use Mir. They target Xorg/Wayland, so they need to find bugs ASAP. What would be better for that task than using Xorg/Wayland all the time they are on a computer?

              3) Exactly. Why else do they want that code upstream?

              4) No, it's not for specific distros only, it's for the whole Linux ecosystem. Mir is NOT for the ecosystem but for Canonical only. See the difference? Technical reasons? Larger code base, so more work needed to maintain it. Also it may introduce new bugs.

              //EDIT: Maybe see it that way:
              All cars use rubber for their wires. All car manufacturers agree that this is the best solution. Now you (as a car manufacturer, too) step up and make steel wires, then go out and tell the streets have to be made of rubber, it won't impact other wires but you need it for yours.
              Last edited by V10lator; 12 July 2013, 05:29 AM.

              Comment


              • #27
                Originally posted by TAXI View Post
                1) Anything to back that up? I see Canonical making red numbers only while Red Hat gets the money. What are REAL Linux users? Desktop users only? Why are server administrators, mobile phone users and so on not real? But after all the size of the distribution doesn't make it more than one, so the single distro argument stays valid. As rvdboom already told: Why does Canonical have to have it upstream when they are the only distribution using it and when they want to maintain it?

                2) Yes, I don't think mesa devs will use Mir. They target Xorg/Wayland, so they need to find bugs ASAP. What would be better for that task than using Xorg/Wayland all the time they are on a computer?

                3) Exactly. Why else do they want that code upstream?

                4) No, it's not for specific distros only, it's for the whole Linux ecosystem. Mir is NOT for the ecosystem but for Canonical only. See the difference? Technical reasons? Larger code base, so more work needed to maintain it. Also it may introduce new bugs.

                //EDIT: Maybe see it that way:
                All cars use rubber for their wires. All car manufacturers agree that this is the best solution. Now you (as a car manufacturer, too) step up and make steel wires, then go out and tell the streets have to be made of rubber, it won't impact other wires but you need it for yours.

                1) Servers do not need that much in terms of X.org/Wayland/Mir. So servers do not impose much requirements on those. Phones are dominated by Android with its own stack. X.org wont be there. Wayland could go there. Mir come from there. But as for now, neither have any significant presence there. So we end up with desktop users. Here Ubuntu is the king.

                2) Here is funny thing. Mesa delivers OpenGL (and other API's) to the LINUX. NOT LINUX BUT MIR. NOT LINUX WHEN XORG OR WAYLAND*. So here goes 1). Should Mesa dev team cut out large portion of Linux users, because they are not interested in supporting them?

                3) Its responsibility of code "submitter" to care about submitted code. Why Wayland folks want their code in upstream Mesa? To forget about it the minute they submit it? Come one. Idea of upstream coop is to work TOGETHER. Frome where come this idea that it MUST be "abandon as soon as its upstreamed". And again. Do you sugest that Canonical WONT care about CRITICALLY IMPORTANT bugs for their MIR stack? (As in: "Wow, Mir wont work on new Mesa.. But that's ok. We do not care. Lets Mesa folks sort it out.... 3 months letter. Wow Mesa folks still didn't fixed it. .... 3y letter. Wow those bugs still there? ..." That is strange notion you have here. Mesa integration is MUST have for Mir. So canonical have all the reasons to care about that code).

                4) Quantify "large code base". And quantify work needed to be done by Mesa contributors who will not work for Canonical nor for MIR. AFTER you have those two data points, lets talk about maintainance burden. (Yes. If burden is hight and Canonical shoulder it on their own upstream its OK. So You NEED to make the distinction of work that could be done by Canonical, and on which could not be..)

                And Mesa already was modified for Wayland. Same will happen for Mir. Exactly paraler situations. Same reqirements for each code authrs from the stand point of Mesa core team. Only trash talking about Canonical, and assumption of best possible perf. on behalf of Wayland authors.

                * At least Intel is working on Mesa + Android.

                Comment


                • #28
                  You seem to consider that Mir is going to be a de-factor standard that everybody in the open source world needs to support because Canonical is backing it.
                  That's just not how it works. Anything which is considered distro-specific is not going to be supported upstream, whether in the kernel, in the low levels libraries or even in the desktop environments. Whether you like it or not, that's how it goes.
                  Because distros go away sometimes, however successful they were at some point.
                  Because developpers do not all run the same distro and they don't want to have to work with distro-specific code, since they can't even check if their last changes broke them or not.
                  Because developers come and go. Because some change their distro once in a while.

                  Mir **IS** currently distro specific. Period. That may change in the future and upstream policies may change accordingly but right now, that's how it is.
                  Wayland patches were accepted in Mesa **because** they are not distro-specific, because most people in the Linux eco-systems, at least in the developpers, believe it will be the standard display server in a few years. And even if Canonical, Red Hat or SuSE disappear, it will remain the standard. Just as X have been (and still is right now).

                  Why it seems so difficult to understand is beyond me...

                  Comment


                  • #29
                    Originally posted by przemoli View Post
                    1) Servers do not need that much in terms of X.org/Wayland/Mir. So servers do not impose much requirements on those. Phones are dominated by Android with its own stack. X.org wont be there. Wayland could go there. Mir come from there. But as for now, neither have any significant presence there. So we end up with desktop users. Here Ubuntu is the king.
                    Servers need Mesa for OpenCL. Phones aren't dominated as the market is still changing (from dump phones to smart phones) so a lot can happen. There are phones with X.org
                    The X Window System software has become the standard graphical interface across Linux & Unix workstations and servers, and has been included in a growing number of mobile phones and tablets in recent years.
                    Source: http://www.x.org/wiki/Other/Press/XorgOIN/

                    Wayland is designed to run on phones, too. In fact is is designed to run everywhere. [EDIT]And there are already companies waiting for Wayland for their mobile OSes[/EDIT].
                    2) Here is funny thing. Mesa delivers OpenGL (and other API's) to the LINUX. NOT LINUX BUT MIR. NOT LINUX WHEN XORG OR WAYLAND*.
                    Can't understand what you want to say, no matter how much you cry.
                    So here goes 1). Should Mesa dev team cut out large portion of Linux users, because they are not interested in supporting them?
                    They cut out nothing. Canonical is able to apply their patches downstream and maintain them there, too. There's absolutely no reason to have them upstream as long as nobody outside of Canonical plans to use Mir. You self proved this by having not a single valid reason why it can't be downstream.
                    3) Its responsibility of code "submitter" to care about submitted code.
                    History told us a different story.
                    Why Wayland folks want their code in upstream Mesa? To forget about it the minute they submit it?
                    You don't know how often that happened, just see ReiserFS, for example (that's one of the reasons the kernel devs didn't wanted to have Reiser4).

                    [EDIT]Not Wayland wanted their code upstream, all distributors (at that time even Canonical) wanted.[/EDIT]
                    Come one. Idea of upstream coop is to work TOGETHER.
                    And why should the Mesa devs help Canonical? Do they get any benefit from that?
                    As in: "Wow, Mir wont work on new Mesa.. But that's ok. We do not care.
                    More like: Wow, Mir wont work on new Mesa.. But Mesa isn't our software, so give the bug report to the Mesa devs. Until it's fixed we will just use the old Mesa version and nobody will notice.
                    That is strange notion you have here. Mesa integration is MUST have for Mir
                    No problem, they can do it downstream.
                    4) Quantify "large code base". And quantify work needed to be done by Mesa contributors who will not work for Canonical nor for MIR. AFTER you have those two data points, lets talk about maintainance burden. (Yes. If burden is hight and Canonical shoulder it on their own upstream its OK. So You NEED to make the distinction of work that could be done by Canonical, and on which could not be..)
                    To get these points the patches have to be upstream first. So why even risk it? Again: It doesn't benefit Mesa nor Canonical.
                    And Mesa already was modified for Wayland.
                    Sure, Wayland is not distro-specific.
                    Same will happen for Mir.
                    Nope, Mir is distro-specific. Stop arguing that away.
                    Last edited by V10lator; 12 July 2013, 07:34 AM.

                    Comment


                    • #30
                      Damn edit limit, forgot something:
                      Originally posted by przemoli View Post
                      Idea of upstream coop is to work TOGETHER.
                      Canonical isn't known to be willing to work together. If they where there would be no Mir in the first place as they would have worked on Wayland (like they promised before Mir).

                      //EDIT: And don't forget that Mesa and Wayland devs are in a good relationship. So Canonical spreading FUD about Wayland doesn't help them getting their patches upstream.
                      Last edited by V10lator; 12 July 2013, 07:42 AM.

                      Comment

                      Working...
                      X