Page 15 of 23 FirstFirst ... 51314151617 ... LastLast
Results 141 to 150 of 224

Thread: The State Of Open-Source Radeon Driver Features

  1. #141
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    Quote Originally Posted by duby229 View Post
    And despite what you say I don't think DRM on linux is even an issue at all. I'm convinced that anybody who uses linux in the first place doesnt care one tiny little bit about DRM, otherwize they wouldnt be using linux. They only things that implement DRM is the proprietary drivers and EVERYTHING else circumvents it. I can't name a single proprietary video player that works well on linux. All of the OSS players are able to work by circumventing DRM.

    I think DRM is nothing more than an excuse.
    What do you think I said.

    One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.

  2. #142
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by bridgman View Post
    Don't think we have ever said that.

    Remember the idea was "we provide info, community writes the driver", not "AMD writes the driver".



    Don't understand this. We run on the common kernel and mesa development cycles. The X driver releases are aligned with kernel & mesa, but the X driver doesn't change much these days since most of the code is now in the kernel.
    Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it. My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.

    And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.

  3. #143
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by bridgman View Post
    What do you think I said.

    One more time, nobody is saying that DRM is required on Linux (although it probably will be on Android). The issue is that DRM *is* a requirement on the other OSes which share code with fglrx, and the DRM requirements of *those* systems are why fglrx needs to stay binary-only.
    But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

    Like I said DRM sounds like a big fat excuse.

  4. #144
    Join Date
    Dec 2007
    Posts
    2,375

    Default

    Quote Originally Posted by duby229 View Post
    And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
    As has been stated previous on a number of occasions, certain features (like UVD) might not be able to be released at all, so we can't target a particular timeline when it's not clear whether that feature will be able to be released at all. We can't speak to when/if something like UVD will be released until all the internal discussions have been resolved and we can say yes or no.

  5. #145
    Join Date
    Dec 2007
    Posts
    2,375

    Default

    Quote Originally Posted by duby229 View Post
    But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux?

    Like I said DRM sounds like a big fat excuse.
    Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.

  6. #146
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    Quote Originally Posted by duby229 View Post
    Please don't get me wrong, I'm very pleased with the OSS drivers, and developers like Marek and Arlied who have the skill to do the actual programming are doing it. It's just that however unfortunate it is developing drivers for GPU's is difficult and complex and very few people have the knowledge and skill set to do it.
    Ahh, so you want to change the deal and have us fund a lot more of the open source driver work. Guess you never watched Transporter

    Quote Originally Posted by duby229 View Post
    My point is that FGLRX is a pile of steaming crap. As it stands if AMD wants a -good- driver the OSS one is a much better point to start from. At least there you'll have a known stable base to build on.
    Remember that fglrx is judged internally against 3D workstation requirements (slow changing enterprise distros, no compositors, very strong 3D focus). Consumer and business client requirements are different and I agree the open source driver is a better fit there.

    Quote Originally Posted by duby229 View Post
    And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
    OK, so you're talking about release of programming information not development. Totally different.

    Remember that we said from the start we were *not* committing to release UVD information, so knock that off your list. I did commit to *trying* and we are making progress there, so complaining that "it's been missing for years" and blaming process is kinda missing the point.

    Power management a bit different but not much -- it went from being "trivial" to "really complex" while we were focused on getting caught up with display/2D/3D driver functionality. We didn't catch that in time (my fault) but have been working on it pretty hard and making good progress. Again, remember that as hard as writing the code is, releasing the programming info is even harder.
    Last edited by bridgman; 01-17-2013 at 12:53 PM.

  7. #147
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    Quote Originally Posted by duby229 View Post
    But not for linux. So exactly what is the point in sharing code for linux when that code isnt needed or wanted or used on linux? Like I said DRM sounds like a big fat excuse.
    Huh ?? Are you possibly thinking that DRM is an isolated little piece of the driver stack ? If so, please understand that it's not like that at all.

  8. #148
    Join Date
    Apr 2010
    Posts
    1,946

    Default

    Quote Originally Posted by duby229 View Post
    And it is of course obvious that you need to allign your development cycle with Xorg and Mesa and the kernel... But that isnt what I'm saying....I'm talking about feature sets. You guys still havent released documents or code for power management or for UVD. These are features that have been missing for years and there have been many xorg and kernel and mesa releases since then. You start target one release cycle and say that by x and x release cycle we will have x and x feature sets done.
    MESA OpenGL level has progressed.
    AMD attitude has not
    They are straight, completely driver-type agnostic, highly passive player unless you bribe($$$) them
    Current bribe list:
    - microsoft ($$$$$$$)
    - hollywood ($$$$$)

    Ask yourself, how can you build anything stable on unstable ground?

    There is also very high probability that (should AMD hardware be released) Android driver will be
    - DRMed
    - closed source
    - financed as seperate entity, cannibalizing on Linux stack

    :begin subliminal message:
    And BTW, your arguing has no use, because you will not be given answers, but excuses.
    If you want your arguing to have response and attitude as if you are customer, buy Windows
    They know how to make open Linux driver better, not you Linux user
    :end subliminal message:


  9. #149
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Well, I just want to say thank you. I disagree with you completely on DRM and FGLRX, but there is nothing I can do about it.

    Please don't misunderstand, I think you guys are doing a fantastic job. And it is good to hear that power management work is coming along. I know that UVD is probably never going to be supported and that when OpenCL gets into a better state at that point an opencl video decoder will be attempted.

  10. #150
    Join Date
    Nov 2007
    Posts
    1,353

    Default

    Quote Originally Posted by agd5f View Post
    Most of the code is shared (modesetting, 3D, multi-media, etc.), not just the DRM related code. Unfortunately, DRM pervades a lot of it so you would effectively have to maintain two trees one with DRM, one without. That kind of defeats the purpose of code sharing.
    I'm saying the should eliminate fglrx completely and maintain zero trees.

Tags for this Thread

Posting Permissions

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