Page 8 of 15 FirstFirst ... 678910 ... LastLast
Results 71 to 80 of 144

Thread: ATi Support on infinityOS

  1. #71
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,545

    Default

    So has XAA (for 2D) and look at all the crap we get for using it

    (slow unminimize after the no-backfill X server patch was yanked from distros)

  2. #72
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,801

    Default

    Quote Originally Posted by bridgman View Post
    Yep, understood. I don't think it was well understood at the beginning that some players were not capable of working with a GL output yet.
    GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx. Since, as you said, features are not a priority for you, then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx? It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

    You can also start a donation effort where people can contribute a few bucks if you're really that poor.

  3. #73
    Join Date
    Dec 2008
    Posts
    1,002

    Default

    But Xv works quite well even nowadays with content up to 720p. The radeon driver surely has no problems with it. Maybe the fglrx devs should take a look at the code, the license is permissive enough to take bits of the code and use it in the proprietary drivers. At least the washed out colors problem should be easy enough to fix in a day.

  4. #74
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by RealNC View Post
    GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx. Since, as you said, features are not a priority for you, then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx? It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

    You can also start a donation effort where people can contribute a few bucks if you're really that poor.
    Perhaps, as per the suggestion earlier in this thread, ATi should make the OSS Radeon drivers the offical "desktop Linux" drivers and gradually add proper OpenGL support (using code from fglrx) via a closed source library. This compromise seems to solve everyone's issues and would make everyone happy.

  5. #75
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,545

    Default

    Quote Originally Posted by RealNC View Post
    GL only solves the wrong color problem, not the vsync one. To go back to what we said earlier, what we really would wish for is DRI2 support in fglrx.
    Why ? You have redirected direct rendering already. DRI2 was a way to get to RDR, albeit with a non-trivial performance hit right now.

    Seriously, my understanding is that vsync *does* work with GL. If it doesn't then please give me some moer details. I don't think Compiz understands vsync properly yet but that's a separate issue.

    Quote Originally Posted by RealNC View Post
    Since, as you said, features are not a priority for you...
    When did I say that ? I said that we were prioritizing some features over others...

    Quote Originally Posted by RealNC View Post
    ... then GL is not a real solution for video. You really need to fix Xv in fglrx. Since the way the open driver does vsync in Xv with DRI1 doesn't seem that complicated, why can't you do the same in fglrx?
    Because all the internal APIs and partitioning of functionality are different, and banging on registers directly in the video stack would cause all kinds of bad things to happen.

    Quote Originally Posted by RealNC View Post
    It's been ages since people were complaining about this. Is the cost of fixing this really that high for such a large, milti-million, world-class corporation like AMD?

    You can also start a donation effort where people can contribute a few bucks if you're really that poor.
    The cost is what we *don't* do as a result of spending time rewriting the video stack. If we don't do the things that we *are* working on that costs us large orders and millions of dollars in lost sales. Contributions welcome.

    I know that in a perfect world we would have a tank of frozen, pre-trained developer clones so we could pull out a few dozen, thaw them out and use them whenever we needed them and throw them back in the tank before the budget runs out, but I've looked all over and haven't found it yet.

    Seriously, if you want to contribute then help push the open source 3D effort ahead or get Compiz vsync working on a wider range of drivers.

  6. #76
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Looking at the license of the Radeon code, it is licensed under MIT, meaning linking to proprietary code is completely allowed. I believe most of not all of X.org is licensed under MIT as well, making the hybrid driver completely possible in terms of legality.

    This solution would be more than satisfactory to much of the opern source community (except for the Free Software Foundation, but who the hell cares what they think anymore).

    The open source community would just prefer if the backend of the drivers is free and open. I know I personally couldn't care less about the 3D libraries, especially if we could easily compile it to use Mesa instead.

  7. #77
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,545

    Default

    Quote Originally Posted by darkphoenix22 View Post
    Perhaps, as per the suggestion earlier in this thread, ATi should make the OSS Radeon drivers the offical "desktop Linux" drivers and gradually add proper OpenGL support (using code from fglrx) via a closed source library. This compromise seems to solve everyone's issues and would make everyone happy.
    Sure, except the internal APIs are totally different. If we grafted the closed source 3D driver onto the open source driver's lower level stack you wouldn't *get* the performance and functionality you want.

    If we grafted the open source X driver onto the proprietary lower level stack (which is what you need for the 3D features and performance) then you lose the simplicity that everyone finds so attractive about the open source driver.

    Seriously folks, we're talking about a 15 million line code base vs a 150,000 line code base. There's a reason you get more features and performance from the proprietary driver.

    What I do think *can* work is opening up more of the interface code between proprietary common modules and the rest of the Linux system, like we do with the kernel compatibility layer today.

  8. #78
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,545

    Default

    I will not use car analogies
    I will not use car analogies
    I will not use car analogies
    ...

  9. #79
    Join Date
    Apr 2010
    Location
    Peterborough
    Posts
    376

    Default

    Quote Originally Posted by bridgman View Post
    Sure, except the internal APIs are totally different. If we grafted the closed source 3D driver onto the open source driver's lower level stack you wouldn't *get* the performance and functionality you want.

    If we grafted the open source X driver onto the proprietary lower level stack (which is what you need for the 3D features and performance) then you lose the simplicity that everyone finds so attractive about the open source driver.

    Seriously folks, we're talking about a 15 million line code base vs a 150,000 line code base. There's a reason you get more features and performance from the proprietary driver.

    What I do think *can* work is opening up more of the interface code between proprietary common modules and the rest of the Linux system, like we do with the kernel compatibility layer today.
    Performance can come with time. We just want something that works. A hybrid driver will provide that in the short term as well as in the long term.

  10. #80
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,545

    Default

    Seriously, a hybrid of the fglrx 3D userspace driver over the open source kernel and X drivers is *not* a short term solution. The internal APIs are totally different and the low level APIs in the fglrx stack explicitly support the upper level functionality. You can't map one on to the other.

    Getting the last few 3D issues worked out on the open source stack is a short term solution. A hybrid open/closed driver is a possible long term solution but not until the open source stack starts to approach fglrx in functionality.

    I guess I don't understand why you think it would be easy.

Posting Permissions

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