Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Mesa Beginning To Need Application Workarounds

  1. #11
    Join Date
    May 2010
    Posts
    135

    Default

    Quote 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.

  2. #12
    Join Date
    Jun 2009
    Posts
    2,908

    Default

    Quote 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.

  3. #13
    Join Date
    May 2010
    Posts
    135

    Default

    Quote 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).

  4. #14
    Join Date
    Oct 2007
    Posts
    1,185

    Default

    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.

  5. #15
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

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

  6. #16
    Join Date
    Oct 2008
    Location
    Sweden
    Posts
    983

    Default

    Quote 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".

  7. #17
    Join Date
    Dec 2010
    Posts
    20

    Default

    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.

  8. #18

    Default

    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.

  9. #19
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote 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.

  10. #20
    Join Date
    Sep 2011
    Posts
    31

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •