Announcement

Collapse
No announcement yet.

AMD's Hawaii Open-Source Support Still Remains Broken

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

  • #31
    Originally posted by bridgman View Post
    Do you envision people buying Hawaii cards to use them with the open source drivers ?
    Yes, I did that. Just as I bought the 4850 when that was pretty new, to use it with the FOSS drivers. I did it to support AMD since they support what I believe in. But I realize that it won't work perfectly at first, or that I will have to wait a while for ot to work at all. But I'm willing to sacrifice that for the thought of supporting the only high performance gpu maker that makes FOSS drivers. Plus, the 7000-cards cost almost as much as the 2-series and I don't want to buy a new card in a year

    Comment


    • #32
      Originally posted by Azpegath View Post
      Yes, I did that. Just as I bought the 4850 when that was pretty new, to use it with the FOSS drivers. I did it to support AMD since they support what I believe in. But I realize that it won't work perfectly at first, or that I will have to wait a while for ot to work at all. But I'm willing to sacrifice that for the thought of supporting the only high performance gpu maker that makes FOSS drivers. Plus, the 7000-cards cost almost as much as the 2-series and I don't want to buy a new card in a year
      OK, noted and understood. Thanks for responding.
      Test signature

      Comment


      • #33
        Originally posted by Azpegath View Post
        Yes, I did that. Just as I bought the 4850 when that was pretty new, to use it with the FOSS drivers. I did it to support AMD since they support what I believe in. But I realize that it won't work perfectly at first, or that I will have to wait a while for ot to work at all. But I'm willing to sacrifice that for the thought of supporting the only high performance gpu maker that makes FOSS drivers. Plus, the 7000-cards cost almost as much as the 2-series and I don't want to buy a new card in a year
        I too follow this use-case. I buy a new top-end card every 2-3 years ($400-750 range) and like to have basic support available in a Linux desktop as I regularly dual-boot, only using Windows for gaming. A stable linux desktop environment on a top-end AMD card with FOSS drivers is definitely preferred.

        Comment


        • #34
          Note that hawaii works correctly with clover and with radeonfb (ie the tty are "accelerated" and Plymouth works) so it's possible to run Xorg without 3d acceleration (if you use Windows to play game) and doesn't need UVD for flash acceleration (I didn"t test if uvd works in tty though). Otoh I don't think people tend to couple hawaii cpu too slow to decode YouTube video.

          The strange thing about hawaii is that it looks like it works under the hood as opencl works without specific workaround (like R600_DEBUG=nodma) and egl* apps sometimes display proper triangle/gears picture, it looks like it fails to present them. Unfortunalty I don't understand precisely how the different blocks work together so it is pure speculation and I can't really help except by testing.

          Comment


          • #35
            Originally posted by vljn View Post
            Note that hawaii works correctly with clover and with radeonfb (ie the tty are "accelerated" and Plymouth works) so it's possible to run Xorg without 3d acceleration (if you use Windows to play game) and doesn't need UVD for flash acceleration (I didn"t test if uvd works in tty though). Otoh I don't think people tend to couple hawaii cpu too slow to decode YouTube video.
            ttys are not accelerated with kms, they are always software rendered.

            Originally posted by vljn View Post
            The strange thing about hawaii is that it looks like it works under the hood as opencl works without specific workaround (like R600_DEBUG=nodma) and egl* apps sometimes display proper triangle/gears picture, it looks like it fails to present them. Unfortunalty I don't understand precisely how the different blocks work together so it is pure speculation and I can't really help except by testing.
            Right. Hawaii is effectively a bigger bonaire. They both have the same 3D programming interface. It probably comes down to some 3D register or registers that need to be programmed slightly differently for hawaii, but so far we haven't been able to track it down.

            Comment


            • #36
              Originally posted by bridgman View Post
              I don't agree, in a number of ways.

              1. Being *told* that something is low priority by the business unit that funds a lot of the open source development (who, incidentally, don't sell any Hawaii-based parts) is one thing, and not caring *yourself* is a very different thing. You seem to be shooting the messenger here -- I realize it's a time-honoured tradition but that doesn't make it a Good Thing.

              2. You seem to be assuming that fixing the problems would be easy, and concluding that since the problems are not fixed then nobody must have worked on it and "nobody cares". Try thinking instead that time *has* been spent on it (enough to bring it up to the same level as the other GCN parts based on experiences with previous generations) but for some reason it's *still* not working, then try working up a new set of conclusions from that.

              Remember there seem to be at least two separate issues here -- the intermittent hangs which drove the initial decision to disable acceleration by default, and some more recent breakage in the code which Michel is working with a customer to fix.
              I don't want to criticize your effort, but this reply has set me wondering:

              ad 1) if the BU in question considers fixing a non-working product a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
              ad 2) i was under the impression that you, the hardware guys, and the catalyst guys are in the same boat, so it would seem that you could reach out to these engineers to help debug the OSS driver?

              Comment


              • #37
                Originally posted by phtpht View Post
                I don't want to criticize your effort, but this reply has set me wondering:

                ad 1) if the BU in question considers fixing a non-working product a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
                ad 2) i was under the impression that you, the hardware guys, and the catalyst guys are in the same boat, so it would seem that you could reach out to these engineers to help debug the OSS driver?
                While I don't agree with statement number one, I do also wonder about number 2. How much are you guys (the two different teams) sharing knowledge and working together? Is it possible for the FOSS team to loan a Catalyst engineer for say a month, both to add (wo)manpower as well as knowledge about the implementation on the Catalyst driver? I know the driver architectures are very similar, but register handling and those low-level hardware parts must be the same, right? Or at least very similar..

                Comment


                • #38
                  Originally posted by Azpegath View Post
                  While I don't agree with statement number one, I do also wonder about number 2. How much are you guys (the two different teams) sharing knowledge and working together? Is it possible for the FOSS team to loan a Catalyst engineer for say a month, both to add (wo)manpower as well as knowledge about the implementation on the Catalyst driver? I know the driver architectures are very similar, but register handling and those low-level hardware parts must be the same, right? Or at least very similar..
                  We already have the teams working closely together, but the drivers are architecturally quite different (memory manager, command submission, fencing, use of DMA etc..). The static register settings are made identical before first support comes is released -- that's what "golden register" settings are for. Generally in a situation like this there is more than one active problem, which means that even correct fixes don't seem to fix it -- so so since Bonaire and Hawaii have a lot in common first priority is to deal with open issues on Bonaire which should reduce the problem space on Hawaii.
                  Test signature

                  Comment


                  • #39
                    OK, I *know* that wasn't 5 minutes...

                    Originally posted by phtpht View Post
                    ... 1) if the BU in question considers fixing a non-working product they don't sell but others do a non-priority, why not just pull the plug on it? the current driver hardly provides any value over the standard vesa driver, so it maybe actually less embarassing and more honest to say hawaii won't be supported due to lack of resources than keeping us in the dark for 9 months. what do you think?
                    Added underlined text to your question above.

                    I don't understand the premise of the question. We have multiple business units, some of whom fund open source driver development, plus core software development funding. The fact that one BU doesn't sell a product doesn't mean we have no resources to work on that product, just fewer resources. This is mostly a more-difficult-to-figure-out-than-usual technical problem.
                    Test signature

                    Comment


                    • #40
                      Originally posted by bridgman View Post
                      We already have the teams working closely together, but the drivers are architecturally quite different (memory manager, command submission, fencing, use of DMA etc..). The static register settings are made identical before first support comes is released -- that's what "golden register" settings are for. Generally in a situation like this there is more than one active problem, which means that even correct fixes don't seem to fix it -- so so since Bonaire and Hawaii have a lot in common first priority is to deal with open issues on Bonaire which should reduce the problem space on Hawaii.
                      Ok, thanks. I just saw that I'd accidentally written "I know the driver architectures are very similar" even though I of course meant the opposite. You've stated several times before that the architecture is very different, so I wanted to assure you that I already knew that. Talk about misfire

                      Comment

                      Working...
                      X