Announcement

Collapse
No announcement yet.

The Experimental GCN 1.0 GPU Support Might Be Dropped From AMDGPU Linux Driver

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

  • #91
    Originally posted by bridgman View Post
    In the meantime we are using driconf and its GUI as a cross-vendor solution for setting and managing 3D driver behavior.

    How? DRIConf hasn't worked in years, it's been over a decade since it was last updated and doesn't at all support Radeon or AMDGPU (having either as a driver string will cause it error out)

    Comment


    • #92
      Originally posted by 8r34k0u7_57y13 View Post
      How? DRIConf hasn't worked in years, it's been over a decade since it was last updated and doesn't at all support Radeon or AMDGPU (having either as a driver string will cause it error out)
      Sorry, should have said drirc rather than driconf.

      That said, I was using driconf recently on a Kaveri system (radeon kernel driver) and it seemed to work OK... will play with it some more and look for bug tickets on it. Thanks.
      Last edited by bridgman; 01-03-2020, 03:30 AM.

      Comment


      • #93
        Originally posted by bridgman View Post

        What decision are you talking about ?

        The only "decisions" I am aware of are (a) Christian deciding to make a casual comment on a mailing list about the *possibility* of retiring amdgpu support for SI parts if we couldn't get the video working and (b) Michael deciding to turn that comment into an article.

        No decisions have been made about amdgpu... everyone seems to be reacting to other people's comments rather than reacting to the article.

        I guess that's the "internet echo chamber" thing everyone talks about

        BTW the article talks about "AMD is unlikely to release" firmware to let UVD work with amdgpu, but that is kind of misleading since it implies that the firmware exists to release. The reality is that the firmware does not exist and does not seem to be feasible due to code size limitations.
        First of all thank you for taking your time answering our questions and giving statements to this topic and even handling some OT issues.
        I wrote the post a bit too hasty - The consideration of dropping GCN 1 turned into a decision of dropping GCN 1.

        Therefore I apologies for further propagating the echo in the chamber.

        But there is one point we can conclude - the majority of the comments here tend to show emotional involvement of the posters (mine included).
        Which is a good sign for AMD: people like the Opensource Efforts. On the other hand deliberations of dropping some support - even reasonable ones - tend to trigger this emotional connotation, because there are this underlying worries of losing the status quo. I don't have to say that Linux support in general is usually treated rather stepmotherly.

        Hence people are clinging the good opensource solutions - we shouldn't be surprised of the reaction if we take a part away (or thinking of taking a part away as in this case).
        Last edited by CochainComplex; 01-03-2020, 04:41 AM.

        Comment


        • #94
          Originally posted by ssokolow View Post

          I've never had an nVidia card outlast its Linux driver support window and Canonical does a good job of picking kernel-driver combinations that Just Work™.

          ...and I don't mean that the hardware died young. Since 2007, I went from a GeForce 7600 to a GT430 to my current GTX750 and both previous cards died in the ~5-6 year window I've come to expect as a reasonable lifespan for a video card in a machine that runs 24/7/365. Heck, the 7600's usable life was ended by having some capacitors go bad, so it could probably be revived.
          It seems you have had good experiences with Nvidia. Tit for Tat. I have the same situation for the red team.
          I don't have my AMD cards situated in a 24/7/365 operation.
          But driving the cards with higher current and voltage can be reasonable considered as accelerated aging if we infer diffusion processes in the semiconductor bulk as cause for major failures of semiconductor devices.
          My (saphirre) 7870 and 7850 are rather strong oced with custom bios (no custom cooler). To buffer the step current changes during operation I have soldered on some additional buffer caps. And I have no issues with this cards even tortured this way since years.

          Back to the topic - In contradiction to nvidia you don't need the driver exclusivly provided by the chip manufacturer to have a good experience. The cards will still work great with the radeon drivers maybe no vulkan but afaik nvidia vulkan support is still experimental in general - again eye for an eye. Nvidia nouveau performance is rather abysmal - no offence the devs are doing a great job but there is no support by nvidia thus forces one to use the only available option:

          Hobson's choice: Proprietery

          The reason Canonical is doing the JustWork thing shows that nvidia drivers are rather picky if they need to have a hand-selected kernel driver combination.
          My odyssey with nvidia drivers (quadro t1000) are supporting this assumption - sure not statistically relevant but crawling through the "help me" threads on the web showed that I m not the only one having a bunch of issues. The driver is also very nitpicking to certain gcc versions.

          Bottom line it is not fun to deal with nvidia drivers in details. So, lucky you Canonical is taking the burden.

          Thats why I have stated: "nvidia is even worse."

          p.s.: 7600 - not sure if it is the caps. usually they use dry polymer caps (ceramic caps are not worth mentioned as failure cause here) these are less prone to get defective compared to the classic 'lytics which indeed are the first devices dying in matured electronic equipment. Just my 2 cents.
          Last edited by CochainComplex; 01-03-2020, 05:31 AM.

          Comment


          • #95
            Originally posted by pal666 View Post
            not really. without uvd you can't watch youtube if your cpu is not high end. and if it is high end, then you don't have gcn 1.0 videocard and you have no such problem. old videocard is enough to watch youtube or play old games
            As far as I know hardware accelerated youtube is not or not easily possible on Linux so far. Therefore it doesn't make a difference. But there's still the possibility of OpenGL video acceleration which needs more energy but works quite well even for older rigs.

            Comment


            • #96
              Originally posted by CochainComplex View Post
              Back to the topic - In contradiction to nvidia you don't need the driver exclusivly provided by the chip manufacturer to have a good experience. The cards will still work great with the radeon drivers maybe no vulkan but afaik nvidia vulkan support is still experimental in general - again eye for an eye. Nvidia nouveau performance is rather abysmal - no offence the devs are doing a great job but there is no support by nvidia thus forces one to use the only available option:
              When I upgrade, Vulkan is going to become important if for no other reason than I was one of the Linux-using suckers who backed Bloodstained: Ritual of the Night (specifically to incentivize the creation of more Linux-native releases) back when it wasn't yet widely known that Kickstarter's ToS is a waste of the time it takes to read it and Wine/Proton-based options for getting it running translate to Vulkan, not OpenGL.

              Originally posted by CochainComplex View Post
              p.s.: 7600 - not sure if it is the caps. usually they use dry polymer caps (ceramic caps are not worth mentioned as failure cause here) these are less prone to get defective compared to the classic 'lytics which indeed are the first devices dying in matured electronic equipment. Just my 2 cents.
              The 7600 had bulging/leaking electrolytics. That's why I could definitively identify them as the points of failure. The GT430 had dry polymer capacitors and has no visible indication of what failed aside from my screens suddenly going dead and the card refusing to POST on reboot, but the system coming back up on the onboard Radeon 6xxx's VGA output when I pulled it.

              Comment


              • #97
                Originally posted by bridgman View Post

                For clarity, driconf is the GUI for the drirc file(s) and is what all the distros include today AFAIK... it's just that driconf does not seem to include support for setting DRI_PRIME yet. The adriconf project is creating an alternative GUI.
                I am sorry. My bad. I think that project is better >>> https://github.com/ChristophHaag/gpuchooser

                I added SOMA (Native OpenGL) to the application, and it switched successfully to my AMD card without using DRI_PRIME=1

                If a database can be added to this project, it will be so useful.
                Last edited by torbido; 01-04-2020, 06:15 AM.

                Comment


                • #98
                  Originally posted by bridgman View Post
                  Right, "all" we need to do is create a magic microcode image that makes make GCN1 hardware behave like a newer GPU when the microcode store is already 100% full. Nothing to do with headers.
                  To be fair, I think this is the first most commenters here are hearing about this issue.

                  Has it been properly communicated by AMD prior to this? Maybe so, and that news was just never publicized here on Phoronix, but I think most people here were under the impression that AMD had been looking into this years ago and then went radio silent on the whole subject.

                  Anyway, at this point I think most people are resigned to not having working UVD support. Halfway recent cpus are generally capable of decoding video it would support anyway, just less efficiently. Dropping Vulkan support for these GPUs would be a much larger issue, even if it's unofficial Vulkan support that AMD doesn't back, because it would essentially make the cards useless for a wide range of gaming these days.
                  Last edited by smitty3268; 01-03-2020, 07:00 PM.

                  Comment


                  • #99
                    Originally posted by smitty3268 View Post
                    To be fair, I think this is the first most commenters here are hearing about this issue.

                    Has it been properly communicated by AMD prior to this? Maybe so, and that news was just never publicized here on Phoronix, but I think most people here were under the impression that AMD had been looking into this years ago and then went radio silent on the whole subject.
                    I have posted about it at least once; I believe agd5f has as well. We didn't realize that anyone was waiting for us to produce the magic microcode though, so there wasn't really any reason for us to communicate about it other than in response to a specific question.

                    If we had to communicate regularly about all the things we are not working on we would never get anything done

                    What we have said more often, however, is that the radeon microcode can be used in its current form as long as the corresponding driver changes (GPU view memory map) are made as well.

                    It should be noted that you *do* have working UVD support today via the radeon driver; it's just amdgpu that doesn't have it yet, and that's one of the main reasons amdgpu is still marked as experimental.

                    It's probably fair to say that people working on the kernel driver think it makes more sense to change Vulkan so it runs on radeon for SI (which may involve extending the radeon ioctls) while people working on Vulkan think it makes more sense to change the amdgpu kernel driver so it supports UVD. Not altogether surprising.

                    The discussion that was mentioned is really about which of those options is better overall.
                    Last edited by bridgman; 01-03-2020, 09:03 PM.

                    Comment


                    • Originally posted by bridgman View Post
                      I have posted about it at least once; I believe agd5f has as well. We didn't realize that anyone was waiting for us to produce the magic microcode though, so there wasn't really any reason for us to communicate about it other than in response to a specific question.
                      Ok. I don't think anyone was really waiting for it anymore, it had become pretty clear it wasn't forthcoming. It just wasn't clear to me there was an actual technical reason behind this, or that it would be difficult to achieve. I think most were under the impression that it was a pretty trivial recompile of the firmware that was required, and that AMD just didn't want to spend the manpower reviewing such a change for old hardware. It's good to know otherwise.

                      Originally posted by bridgman View Post
                      It should be noted that you *do* have working UVD support today via the radeon driver; it's just amdgpu that doesn't have it yet, and that's one of the main reasons amdgpu is still marked as experimental.
                      Right. To clarify, I was just pointing out that gamers are all running amdgpu today, because Vulkan support is essential and UVD is only a nice-to-have. But non-gamers are likely all using the default radeon driver and getting UVD.
                      Last edited by smitty3268; 01-03-2020, 09:29 PM.

                      Comment

                      Working...
                      X