Announcement

Collapse
No announcement yet.

Mesa Beginning To Need Application Workarounds

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

  • #11
    Originally posted by pingufunkybeat View Post
    These forums have long passed the point of no return. I give up.

    Mesa GL workarounds for the love of the hungry children worldwide. You can make a difference!
    I guess you miss the point. The point is that we can wait for perfection before we go on to fix these incompatibilities. People have real apps that they want to use, that don't work, and the easiest and most reasonable solution is a shim or workaround of some sort. Mesa will never have a fully functioning stack. It's been, what, 15 years or more that the project has existed and we are now struggling to talk about reaching minimum 3.0 GL requirements (when 3.0 was released almost 4 years ago), to say nothing of good performance for the parts that are actually implemented. If we wait for a perfect implementation before addressing broken apps, we will never arrive. Mesa has to address both the need to reach GL compliance and the need for people to get real work done today. That entails compromises. In the same way that it'd be great if everyone in the world could be fed and clothed before we move on to bigger things, but because of the complexities involved, it's better to let some people move on to greater things before everyone is clothed and fed -- so too in the world of Mesa is it necessary to make compromises and provide workarounds even when, in a perfect world, we wouldn't.

    Comment


    • #12
      Originally posted by siride View Post
      I guess you miss the point. The point is that we can wait for perfection before we go on to fix these incompatibilities.
      It's not about perfection, it's about priorities.

      Closed drivers have more workarounds than the entire Mesa stack + all of the linux kernel tree. OpenGL compliance (and other things I mentioned) are not only more important IMHO, but also more realistic than duplicating all those workarounds.

      If a couple of high-profile workarounds make it into the tree and don't cause an unmaintainable mess, I won't complain -- it's the developers' choice after all. I just don't think that Unigine demos are all that important compared to power saving, for example.

      Comment


      • #13
        Originally posted by pingufunkybeat View Post
        It's not about perfection, it's about priorities.

        Closed drivers have more workarounds than the entire Mesa stack + all of the linux kernel tree. OpenGL compliance (and other things I mentioned) are not only more important IMHO, but also more realistic than duplicating all those workarounds.
        Well, if you don't want to duplicate the work of the closed source drivers, then we should just stop developing the Radeon and nVidia open source drivers, because the whole thing is a duplication. Do you want the Open Source drivers to work, or do you want to be able to claim some sort of moral high ground?

        If a couple of high-profile workarounds make it into the tree and don't cause an unmaintainable mess, I won't complain -- it's the developers' choice after all. I just don't think that Unigine demos are all that important compared to power saving, for example.
        True. Fixing every little bug is unnecessary (and wouldn't happen anyway because of lack of manpower).

        Comment


        • #14
          If it means bloating the code base and wasting precious dev hours on working around buggy programs, then I don't care if games target linux or not. Those games should be able to write good openGL-compliant code or they shouldn't bother.

          Comment


          • #15
            Unigine folks already said these are fixed? Carry on on the general case though

            Comment


            • #16
              Originally posted by curaga View Post
              Unigine folks already said these are fixed? Carry on on the general case though
              Depends if it just OilRush or if they are planning on releasing new versions of the benchmarks too.

              In other news, Super Meat Boy and Shank still doesn't run on Mesa out-of-the-box, because it is "asshole correct".

              Comment


              • #17
                i think workarounds should be handled off-tree in a seperate package, maybe through api.
                that way its easy for users to choose if they want only specification compliance or compatibilty, maybe even easily switchable by configs files.

                Comment


                • #18
                  i (half seriously) propose charity bug bounties.

                  "I pledge to donate ?x to charity y when bug #z is fixed."

                  This should help solve all the worlds problems.

                  Comment


                  • #19
                    Originally posted by lopho View Post
                    i think workarounds should be handled off-tree in a seperate package, maybe through api.
                    that way its easy for users to choose if they want only specification compliance or compatibilty, maybe even easily switchable by configs files.
                    Anholt's proposal already addresses that, I think. The idea is that although the workarounds are in the Mesa code base, they're individually enabled/disabled/mapped to applications via drirc. This is far better than a global "quirks mode / standards mode" switch.

                    Comment


                    • #20
                      Originally posted by siride View Post
                      You really want to make sure that nobody targets Linux, eh?
                      You really want to make sure that Linux is as sloppy as Windows, eh?

                      Comment

                      Working...
                      X