Announcement

Collapse
No announcement yet.

2013: A Good Year For Open-Source AMD?

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

  • #41
    Originally posted by Qaridarium
    also Bridgman should be proud of his enemies and maybe his colleagues are proud about his skill in fighting against open source fan-boys ?
    Someone has a high opinion of themselves. It's you.

    I'm pretty sure he doesn't give you a second thought when he's not on these forums.

    Comment


    • #42
      Does every fcking thread have to end like this? Guys there is a function called "Ignore List". Use it!

      Comment


      • #43
        Originally posted by bridgman View Post
        Hmm, that doesn't sound right. There should be significant differences between profiles.

        There are some systems where the vendors only added a single power setting in the VBIOS (which means more complex code is needed in the kernel driver) but I didn't think we had those with HD3200. Might ask you to file a bugzilla ticket with a VBIOS dump, will see what agd5f suggests.

        Power management doesn't seem to be one of those areas that community developers work in for fun (as libv pointed out recently) so we might have to go back and give that code another kick.
        I don't think thats fair at all, the problem is the hw is capable of doing much more, so if I spent 2-3 months making dynpm better, it would all be thrown away when we actually get to what the hw can do. The fact I know what the hw can do means I've no incentive to work on half-assed approaches just because AMD don't want to tell anyone that their pm hw works nearly exactly like the nvidia pm hw.

        Dave.

        Comment


        • #44
          I guess you're right about motivation, although I don't think either agd5f or I expected you to be the one working on the current PM implementation.

          That said, a lot of initial implementations are written knowing that they may be replaced at some point (eg the initial r600g shader compiler), but those initial implementations still provide useful functionality for long enough to justify the effort. For better or for worse I did expect that someone would see PM the same way and push it ahead during the last couple of years, although it's clear now that was a bad assumption on my part.
          Last edited by bridgman; 05-25-2012, 08:05 AM.

          Comment


          • #45
            Does airlied means that there is not enough documentation to fully exploit the PM capabilities or i am reading something the wrong way??

            Comment


            • #46
              Originally posted by bridgman View Post
              Currently the proprietary drivers (all of them AFAIK) replace a lot of the open source graphics stack with proprietary interfaces. Until similar improvements are made in the generic open source framework, which *will* take a fair amount of time and effort, there will be gaps between open source and proprietary stacks. I am agitating internally for our proprietary driver folks to help where they can by pushing enhancements into the common framework where possible, and should know the outcome in early 2013.
              Are you talking about improving the kernel KMS/DRM code to the point Catalyst can use it instead of its own kernel blob or was that about other parts of the graphics stack?

              Comment


              • #47
                Originally posted by 89c51 View Post
                Does airlied means that there is not enough documentation to fully exploit the PM capabilities or i am reading something the wrong way??
                It's complicated, so you're probably just reading it correctly

                PM basically works by changing clocks and voltages to make power/performance tradeoffs that match the user's needs.

                For r600 and earlier the driver code set clocks and voltages directly. On most of the more recent hardware generations the driver can still set clocks and voltages directly but each generation has different hardware blocks added which can set those clocks and voltages automatically with guidance from the driver. So far we have not been allowed to release info for those additional HW blocks, although as with UVD we have been working internally to change that. The difference is that we started internal discussions about PM a couple of years ago, concluded that we were not going to get quick approval, and that's why the current PM code was developed.

                The current PM implementation sets clocks and voltages directly so it works on all generations of hardware. My thinking was that the code would need to be worked on anyways to provide better PM for r600 and earlier, and that work would benefit newer hardware as well although there would probably be a need for per-generation work to deal with HW quirks.

                I think Dave is saying "why work on the current code if we know it's going to be thrown away in the future ?", which is fair, but (a) we *don't* know that the work will be thrown away in the future for newer chips (although the chances have been gradually improving over the last year or so), and (b) I believe the same work needs to be done for earlier parts anyways.

                Comment


                • #48
                  Originally posted by bridgman View Post
                  The difference is that we started internal discussions about PM a couple of years ago, concluded that we were not going to get quick approval, and that's why the current PM code was developed.
                  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?

                  Comment


                  • #49
                    Cards which work

                    I got myself a netbook ~1 year ago with an AMD C-50 APU and it works great from day one with the open driver.
                    In my laptop is an AMD 6970M and this card also works great (it got fried once, because I am an idiot and used conducting heat-paste which spread over the card). The Vendor shipped it to AMD and they replaced it...

                    Before that, I had HD4770 which was when the open driver just came out and there were screen corruptions all the time. Compared to that is the open driver close to perfect by now. Just see how much progress got accomplished in only ~3 year?!?

                    OK, I am an AMD Fanboy, because the last good Nvidia Card I possessed was a Riva TNT1 (still got a 460M for the laptop as replacement but don't use it)
                    Last edited by disi; 05-25-2012, 10:45 AM.

                    Comment


                    • #50
                      Originally posted by entropy View Post
                      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?
                      Nope. Same goes for all of the programming info... the best we can do is give rough estimates and confidence levels in cases where we have a specific list of tasks to complete before we can release, but this is more like UVD where we don't know what the outcome will be until the last minute.

                      As soon as we get to the point where the remaining issues can be discussed in public, we release
                      Last edited by bridgman; 05-25-2012, 11:19 AM.

                      Comment

                      Working...
                      X