Announcement

Collapse
No announcement yet.

Mesa Beginning To Need Application Workarounds

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

  • Mesa Beginning To Need Application Workarounds

    Phoronix: Mesa Beginning To Need Application Workarounds

    Now that Mesa is beginning to catch-up with support for newer versions of OpenGL and the OpenGL performance is slowly improving, with more games and applications beginning to work on this open-source graphics driver stack as a result, the need for application workarounds is becoming more prevalent...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    The driver should NOT contain application specific workarounds. If the application is defective, the application developer should fix it to comply with the standards. Application specific workarounds do nothing except let the application developers write shoddy non-compliant code and cause the drivers to bloat out needlessly.

    Comment


    • #3
      april's fool! ...i hope

      why would software devs miss the compliance intentionally? is this some kind of academic homour?
      is there nothing to do on the intel side (like maybe getting on the gallium3d arch) but fixing elderly tech temos?

      Comment


      • #4
        Originally posted by droidhacker View Post
        The driver should NOT contain application specific workarounds. If the application is defective, the application developer should fix it to comply with the standards. Application specific workarounds do nothing except let the application developers write shoddy non-compliant code and cause the drivers to bloat out needlessly.
        A working system requires compromises.

        Comment


        • #5
          3 simple universal workarrounds

          1. Fix the bugs when they occur in non-proprietary code
          2. Notify the authors of the problem app that they need to comply or fix bugs in then and fix their non-proprietary code when they don't
          3. If the problem is in proprietary code, inform the authors of simple universal workaround option 2. If this fails, ignore the problem proprietary code and instead confirm that the all the non-proprietary alternatives are working. Because why should non-proprietary authors waste their valuable time fixing code that someone else got paid to slop up?
          Last edited by zerothis; 26 January 2012, 11:21 AM.

          Comment


          • #6
            Originally posted by zerothis View Post
            Because why should non-proprietary authors waste their valuable time fixing code that someone else got paid to slop up?
            Because Unigine SUPPORTS LINUX.

            Comment


            • #7
              Originally posted by zerothis View Post
              1. Fix the bugs when they occur in non-proprietary code
              2. Notify the authors of the problem app that they need to comply or fix bugs in then and fix their non-proprietary code when they don't
              3. If the problem is in proprietary code, inform the authors of simple universal workaround option 2. If this fails, ignore the problem proprietary code and instead confirm that the all the non-proprietary alternatives are working. Because why should non-proprietary authors waste their valuable time fixing code that someone else got paid to slop up?
              You really want to make sure that nobody targets Linux, eh?

              Comment


              • #8
                Originally posted by siride View Post
                You really want to make sure that nobody targets Linux, eh?
                When we have a well-performing, OpenGL 4.2 compliant support in Mesa, with functioning powersaving, video decoding and a compliant and performant OpenCL stack, then we can start thinking whether it is time to send 50 developers (who don't exist) to add ugly hacks to support non-OpenCL compliant software.

                Comment


                • #9
                  Originally posted by pingufunkybeat View Post
                  When we have a well-performing, OpenGL 4.2 compliant support in Mesa, with functioning powersaving, video decoding and a compliant and performant OpenCL stack, then we can start thinking whether it is time to send 50 developers (who don't exist) to add ugly hacks to support non-OpenCL compliant software.
                  How can we justify these people working on video drivers when kids are starving in Africa?

                  Comment


                  • #10
                    Originally posted by siride View Post
                    How can we justify these people working on video drivers when kids are starving in Africa?
                    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!

                    Comment

                    Working...
                    X