Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: Mesa Beginning To Need Application Workarounds

  1. #1
    Join Date
    Jan 2007
    Posts
    14,770

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

    http://www.phoronix.com/vr.php?view=MTA0ODY

  2. #2
    Join Date
    Oct 2009
    Posts
    2,108

    Default

    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.

  3. #3
    Join Date
    Jul 2009
    Posts
    256

    Default

    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?

  4. #4
    Join Date
    Jul 2007
    Posts
    241

    Default

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

  5. #5
    Join Date
    Sep 2011
    Posts
    35

    Default 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; 01-26-2012 at 10:21 AM.

  6. #6

    Default

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

  7. #7
    Join Date
    May 2010
    Posts
    135

    Default

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

  8. #8
    Join Date
    Jun 2009
    Posts
    2,929

    Default

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

  9. #9
    Join Date
    May 2010
    Posts
    135

    Default

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

  10. #10
    Join Date
    Jun 2009
    Posts
    2,929

    Default

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

Posting Permissions

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