Announcement

Collapse
No announcement yet.

2013: A Good Year For Open-Source AMD?

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

  • ChrisXY
    replied
    Originally posted by Qaridarium
    ok then in "video playback" and "power-management" the spec and AMD support is a lie...
    There's still a little difference in "good enaugh so it works, but not as good as it possibly could" and "a lie".

    Leave a comment:


  • curaga
    replied
    Originally posted by bridgman View Post
    Don't think we were talking about turning UVD off -- I was talking about decoding video with it.
    Of course I meant "UVD and other unused blocks on the card", but didn't quite phrase that right.

    Leave a comment:


  • airlied
    replied
    Originally posted by Qaridarium
    If reverse engineering the FGLRX is more useful than using specs from AMD then the hole support from AMD is a lie?

    or maybe i didn't understand you here.
    yeah you didn't understand because I never said it in a general way. We just know in some cases that fglrx uses the hw in ways that the docs don't/won't cover, e.g. UVD. In most cases this isn't true, and its fine to never RE fglrx, because the docs are fine.

    So really in most cases I wouldn't dream of RE'ing fglrx since we have good enough docs/access to engineers.

    Leave a comment:


  • smitty3268
    replied
    @bridgman
    is there still work being done for the UVD ???
    Originally posted by bridgman View Post
    Yes, although we're not at the point where I can say anything more encouraging than before about chances of exposing the HW.
    What about the video encoder that the new chips have?

    I'm not particularly in a hurry to get support for it, I'm just wondering if it's a minefield of patents/lawyers as well, or if you think that would be easier than decoding through UVD.

    Leave a comment:


  • smitty3268
    replied
    Can you share with us _why_ this turns out to be problematic?
    I think it's obvious for the UVD blocks - but for the PM bits?
    Originally posted by bridgman View Post
    Nope. Same goes for all of the programming info...

    Leave a comment:


  • Hamish Wilson
    replied
    Just to add some common decency and politeness to this thread: I wish to offer my thanks to bridgman, agd5f, airlie, and everyone else who is working on improving these drivers. If it was not for your hard work we would not have anything to talk about here at all, and everyone should be grateful. I at least appreciate your efforts.

    Now, was that so hard everyone?

    Leave a comment:


  • DanL
    replied
    Originally posted by Qaridarium
    well the clue is to call a opponent with dissenting opinions a "Contrarian Troll" is the first step to be the Contrarian Troll
    ...
    Accusing the accusers. When confronted with their trolling, trolls immediately respond that it is the accusers who are trolls.
    You made my day. Thanks.

    Leave a comment:


  • bridgman
    replied
    Originally posted by 89c51 View Post
    @bridgman
    is there still work being done for the UVD ???
    Yes, although we're not at the point where I can say anything more encouraging than before about chances of exposing the HW.

    Leave a comment:


  • 89c51
    replied
    @bridgman


    is there still work being done for the UVD ???

    Leave a comment:


  • airlied
    replied
    Originally posted by ChrisXY View Post
    I think many people (like me) who say they would like better power management aren't even talking about automatically adjusting power levels to "match the user's needs". It's still that on "low" power level my HD 6550M drains more power than catalyst by default. (Last time I tried "low" it sometimes crashed so I used "mid" since then which seems to be exactly the same but at least appeared to be more stable).

    What I personally think should be the priority in power management is bringing the card down to the minimum power drain possible for the "low" profile.

    Code:
     % sudo su -c "echo low > /sys/class/drm/card0/device/power_profile"
     % cat /sys/kernel/debug/dri/0/radeon_pm_info
    default engine clock: 600000 kHz
    current engine clock: 299970 kHz
    default memory clock: 800000 kHz
    current memory clock: 299950 kHz
    voltage: 900 mV
    PCIE lanes: 16
     % sudo su -c "echo mid > /sys/class/drm/card0/device/power_profile"
     % cat /sys/kernel/debug/dri/0/radeon_pm_info
    default engine clock: 600000 kHz
    current engine clock: 299970 kHz
    default memory clock: 800000 kHz
    current memory clock: 299950 kHz
    voltage: 900 mV
    PCIE lanes: 16
    Yeah I suspect there are block on the gpu that fglrx powers off dynamically to get even lower than the min one.

    I'm not sure, if anyone was going to work on power saving I'd recommend the nouveau approach and reverse engineer fglrx rather than talking to AMD, and definitely try not be covered by an NDA.

    While improving the current code might be worth it for a while, its suboptimal in the long term, and reverse engineering fglrx would probably produce a much more useful benefit.

    Dave.

    Leave a comment:

Working...
X