Announcement

Collapse
No announcement yet.

amd-staging-4.6 for Fedora 24 (AMDGPU)

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

  • #21
    Originally posted by kgonzales View Post

    So I just retested this morning, removing all the griever packages and going back to just Fedora 24 packages. Once that was done, I installed your AMDGPU package and your AMD staging kernel, and rebooted. I have two issues with your repos:

    1) With your kernel (4.6.6 one, the 4.6.7 was not showing in the repos) and your linux-firmware package, I get a traceback and cannot continue.
    2) With the latest Fedora kernel and your Mesa and AMDGPU packages, I cannot log into GNOME.

    So I cleared out your packages again, reinstalled the griever package. Everything is working again with a small performance boost.

    I rebuilt your most recent AMDGPU package against the griever devel bits. It worked without issue, but I did not see a difference in performance (maybe a 1-2 frame regression) or any graphical changes. Maybe that's a good thing?

    I feel like I am still missing something tho. The kernel with the new AMDGPU model and DAL commits should "just work" unless its NOT written with laptops in mind. bridgman do you have any input here?

    I may try to manually install your most recent kernel, and try again.
    A few comments on my end:

    - According to AMD's AMDGPU-Pro website, AMD Radeon™ R9 M395X Graphics is listed, so I would assume it should be supported by this kernel ( note that haven't looked into the code for your card). I would still verify that the radeon driver isn't being used instead of amdgpu, and if it is, I would blacklist the "radeon" module temporarily to see if it works. It may or may not be supported by mesa yet, though I would assume it should be agnostic enough for it not to matter.

    - If the new linux-firmware indeed does not work, regardless of what kernel you are using, I would report it to AMD, as I know the Tonga firmware was updated since I pulled the binaries for that package. There could be a regression there.

    - Let me know if using stock linux-firmware with my kernel build works, it shouldn't matter what mesa you are using providing it's recent. There maybe a regression in the staging branch itself pertaining to your card.

    - Honestly, using AMDGPU may not be valuable for your card unless it improves stability or adds a feature you want. Performance wise, I don't believe it will do much, but note that this is conjecture, I am not an AMD developer.

    Comment


    • #22
      Originally posted by bridgman View Post

      I expect most of the testing has been using desktop parts so far, although the code should be the same between desktop/laptop other than laptops having a greater number of scenarios where bugs can be lurking.
      Well because I was curious I now have laptops running both M375 and M395X video parts. I wanted to test the open source drivers for the AMD cards, so I am more than willing to do testing. None of these are my daily driver laptops.

      Originally posted by bridgman View Post

      I'm having a bit of trouble understanding exactly what you are running. When you talk about mystro256's AMDGPU package is that the "4.6 staging plus some other backported fixes" kernel or are you talking about something related to the AMDGPU PRO (hybrid) stack ? Or maybe the amdgpu X driver ? (I thought most distros were using modesetting X driver rather than amdgpu at the moment but not 100% sure).

      Normally I only see AMDGPU (all caps) used in the pro/hybrid context, plus you mentioned not seeing performance differences and I wouldn't expect a performance difference just from updating kernel driver. AFAIK the 4.6-staging tree is just a periodically-refreshed copy of our internal staging tree.

      I do seem to remember people reporting issues with Gnome using the hybrid stack (maybe an EGL issue with closed-source GL ?) but not with the open stack. Unfortunately I'm not sure which one you are running...
      There are 4 scenarios I have tested:

      1) Fedora 24 with updates, only using the distro repos

      This works, is stable.

      2) Fedora 24 with updates, and also the griever copr repo enabled which provides Mesa updates from upstream Git: https://copr.fedorainfracloud.org/co...ever/mesa-git/

      This also works, is stable and is about 3-5% better performing than Fedora 24 updates only

      3) Fedora 24 with updates, and also the various mystro256 reps found here: https://copr.fedorainfracloud.org/co...6/polaris-gfx/

      These repos contain a rebuilt Fedora kernel with the following changes:

      "This is an unofficial Fedora 24 build of AMD's staging kernel with all the security patches included in Fedora and upstream patches from kernel.org. Feel free to bug me if this gets out of date. (I.e. a new Fedora kernel is released) This kernel has the upstream code for AMDGPU, freesync, DAL, audio over HDMI for the newer cards (e.g polaris), plus everything that has yet to make it into the mainline kernel."

      It also has some Mesa updates and the package called xorg-x11-drv-amdgpu.

      The most recent kernel build I tested (4.6.6-901.amd.03082016.fc24) does not boot on my system. And the AMDGPU package, while roughly the same performance as Mesa GIT updated, has more graphical distortion.

      4) Fedora 24 with update, the griever copr repo enabled, and a local package build for xorg-x11-drv-amdgpu against the devel packges from Mesa Git.

      Same as above, the AMDGPU package, while roughly the same performance as Mesa GIT updated, has more graphical distortion.

      Mystro256 mentioned that he just updated Mesa and I see a new kernel to test, which I will do later today.

      Does this help? Clear as mud?




      Comment


      • #23
        Originally posted by bridgman View Post

        I expect most of the testing has been using desktop parts so far, although the code should be the same between desktop/laptop other than laptops having a greater number of scenarios where bugs can be lurking.

        I'm having a bit of trouble understanding exactly what you are running. When you talk about mystro256's AMDGPU package is that the "4.6 staging plus some other backported fixes" kernel or are you talking about something related to the AMDGPU PRO (hybrid) stack ? Or maybe the amdgpu X driver ? (I thought most distros were using modesetting X driver rather than amdgpu at the moment but not 100% sure).

        Normally I only see AMDGPU (all caps) used in the pro/hybrid context, plus you mentioned not seeing performance differences and I wouldn't expect a performance difference just from updating kernel driver. AFAIK the 4.6-staging tree is just a periodically-refreshed copy of our internal staging tree.

        I do seem to remember people reporting issues with Gnome using the hybrid stack (maybe an EGL issue with closed-source GL ?) but not with the open stack. Unfortunately I'm not sure which one you are running...
        If it helps clarify things, this is the open stack. I don't believe there's a way to run the hybrid stack on fedora. I'm assuming it's due to differences in the Ubuntu stack and the Fedora stack causing conflicts (userspace always crashes Xorg). When a RHEL version comes out, it may work, as the stack is very similar to fedora.

        The kernel I'm providing is a pull of the amd-staging-4.6 code, plus applicable 4.6.7 patches (some are already applied in the code), plus RedHat's patches, which comes with the Fedora kernels.

        The Xorg driver is a pull of the amdgpu git from freedesktop.org from around the end of July (this commit). I pulled this rather than the stable 1.1.0 version, as there are fixes for Polaris, which I use on my desktop computer at home. Mode-setting does work, but I find the specific drivers are a little better for the time being.

        And finally, if valuable, my Linux-firmware includes this git commit, which updated the tonga firmware:

        Which kgonzales says does not work, but I'm not 100% sure where the issue lays here.

        PS: I would love to change the title of this article to (amdgpu) instead of the caps... but I can't edit anything anymore :/

        Comment


        • #24
          Originally posted by bridgman View Post
          ...
          I posted a response but I think it's in limbo right now..

          Comment


          • #25
            Originally posted by Mystro256 View Post

            I posted a response but I think it's in limbo right now..
            Mine was as well. The forum is great until you actually use it.

            I will try your suggestions above throughout the day and see if anything changes. I am hoping they do. These laptops with AMD video cards are heavily discounted across Ebay and elsewhere, and are pretty good and inexpensive open source gaming systems. The Alienware 15 R2 was less than $1300, and that was with the M395X and a 256Gb NVMe SSD.

            Comment


            • #26
              Originally posted by kgonzales View Post
              ...

              3) Fedora 24 with updates, and also the various mystro256 reps found here: https://copr.fedorainfracloud.org/co...6/polaris-gfx/

              These repos contain a rebuilt Fedora kernel with the following changes:

              "This is an unofficial Fedora 24 build of AMD's staging kernel with all the security patches included in Fedora and upstream patches from kernel.org. Feel free to bug me if this gets out of date. (I.e. a new Fedora kernel is released) This kernel has the upstream code for AMDGPU, freesync, DAL, audio over HDMI for the newer cards (e.g polaris), plus everything that has yet to make it into the mainline kernel."

              It also has some Mesa updates and the package called xorg-x11-drv-amdgpu.

              The most recent kernel build I tested (4.6.6-901.amd.03082016.fc24) does not boot on my system. And the AMDGPU package, while roughly the same performance as Mesa GIT updated, has more graphical distortion.

              4) Fedora 24 with update, the griever copr repo enabled, and a local package build for xorg-x11-drv-amdgpu against the devel packges from Mesa Git.

              Same as above, the AMDGPU package, while roughly the same performance as Mesa GIT updated, has more graphical distortion.
              You referred to "the AMDGPU package" in two places here, but I'm still not sure what "the AMDGPU package" is. Sorry, maybe I'm just slow today.
              Test signature

              Comment


              • #27
                Originally posted by kgonzales View Post

                Well because I was curious I now have laptops running both M375 and M395X video parts. I wanted to test the open source drivers for the AMD cards, so I am more than willing to do testing. None of these are my daily driver laptops.



                There are 4 scenarios I have tested:

                ...
                The one last scenario I'm curious about: use the mesa-git, but test with and without the staging kernel (i.e. none of the other stuff i provided). amdgpu or radeon should kick in; if radeon kicks in, blacklist it and see if amdgpu works.

                Something could have broke in staging. I've been looking through it for the past month or so; I already found one error and sent them a patch, which was committed a week ago. The staging code is still definitely a WIP, though an increasingly more stable WIP.

                As bridgman previously mentioned, the specific xorg driver isn't required to use the amdgpu module, I just figured it would work better than the generic modesetting.

                Comment


                • #28
                  Mystro256 Here are some updates:

                  1) The newest kernel build (kernel-4.6.7-901.amd.16082016.fc24.x86_64) will boot on my system without issues.
                  2) I have load your bits (your Mesa build, your X.org AMDGPU driver, your AMD staging kernel), and the system is using both your kernel and the X.org AMDGPU driver.
                  3) The performance of this stack is less good than the griever Mesa git repo, by about 3-5%. I have more graphical artifacts with your stack (but to be honest, the open drivers have graphical artifacts, period) and also more screen tearing.

                  So. Your stuff works, but as you mentioned in an earlier post... this does not appear to be improving performance. And with the patch earlier mentioned improved performance in the radeon driver for muxless systems with SI/VI cards improving DRI_PRIME performance (literally my top use case), I am moving back to the griever repo. However, if you have something new you are interested in having me test, please let me know! I have also learned my way around the advanced commands for DNF during this exercise, and its now WAY easier to switch between repos.

                  Comment


                  • #29
                    Originally posted by bridgman View Post

                    You referred to "the AMDGPU package" in two places here, but I'm still not sure what "the AMDGPU package" is. Sorry, maybe I'm just slow today.
                    It's not you. I had two things I was testing: the X.org AMDGPU driver, and a kernel built with patches from staging to support the AMDGPU driver. Is that more clear?

                    Comment


                    • #30
                      It's getting there... which of those two is "the AMDGPU package" ? Or does it depend on context ?
                      Test signature

                      Comment

                      Working...
                      X