Announcement

Collapse
No announcement yet.

The State Of Open-Source Radeon Driver Features

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

  • duby229
    replied
    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.

    Leave a comment:


  • crazycheese
    replied
    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:

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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

    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.

    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; 17 January 2013, 01:53 PM.

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


  • agd5f
    replied
    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.

    Leave a comment:


  • duby229
    replied
    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.

    Leave a comment:


  • duby229
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by bridgman View Post
    Right. If we had been writing a separate Linux driver (rather than code sharing) it would be open source.

    One thing I've said a lot of times is that ability to share code across multiple OSes is the primary reason for proprietary drivers to exist.

    You pretty much have to take the secrecy requirements of all the OSes sharing code and follow the most restrictive of them all, which is how shared-code drivers like Catalyst Linux (and the corresponding NVidia drivers) end up being proprietary. We are the only vendor willing to support both proprietary drivers (for workstation and other performance-critical markets) AND open source drivers.

    Note that the 3D workstation drivers have historically been associated with high end GPUs, which we make but not everyone does. If we hadn't made big-ass GPUs we probably wouldn't have needed a workstation driver in the past. Things are getting interesting now because high end APUs (eg Trinity/Richland) have enough HW performance to be viable at the low end of the workstation market, given the right drivers.
    I've seen some numbers recently on workstation GPU market, and AMD isnt doing very well there. FGLRX isnt stable and most folks who use linux know that. They stay away from it like it was a plague. I think you'd be much better off putting your resources into the OSS side of the equation. At the very minimum it is stable. It just needs support for the features that the hardware provides.

    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.

    Leave a comment:

Working...
X