Announcement

Collapse
No announcement yet.

amd-staging-4.6 for Fedora 24 (AMDGPU)

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

  • Originally posted by Shalrath View Post
    I've noticed that the latest builds of amd-staging now support amdgpu on my crappy R9-270. Kudos to Mystro256.

    So here's a question. Am I actually using some brand new graphics driver, or does amdgpu recycle the older radeonsi code for GCN1.0 devices? I noticed that I was still locking up while playing TF2 on the 4.9-wip kernel.
    You are using a new kernel graphics driver (based on radeon kernel driver code but heavily refactored), while the same radeonsi Mesa driver is used whether you are running with radeon or amdgpu kernel drivers. I wouldn't call it "recycle", there was simply no reason to change.
    Test signature

    Comment


    • Originally posted by debianxfce View Post
      amd-staging has DAL, drm-next does not. Otherwise they seem to get same patches.
      Yep.. the other difference is that drm-next follows the latest WIP kernel code, while amd-staging follows released kernels. It attempts to strike a balance between upstream and the older kernels most of our customers are actually using.
      Test signature

      Comment


      • Originally posted by Shalrath View Post
        I've noticed that the latest builds of amd-staging now support amdgpu on my crappy R9-270. Kudos to Mystro256.


        So here's a question. Am I actually using some brand new graphics driver, or does amdgpu recycle the older radeonsi code for GCN1.0 devices? I noticed that I was still locking up while playing TF2 on the 4.9-wip kernel.

        The bug is a well known issue in mesa, thus would affect both radeon and amdgpu. This is not a bug in amdgpu.

        The upstream bug report is here:

        Comment


        • Originally posted by Mystro256 View Post

          The bug is a well known issue in mesa, thus would affect both radeon and amdgpu. This is not a bug in amdgpu.

          The upstream bug report is here:

          https://bugzilla.freedesktop.org/show_bug.cgi?id=95308
          Has it been a known bug? Yes. But I've had the issue with fglrx, mesa 11 and mesa 12. And it only happens if multicore rendering is enabled. The same crash happens in Half-Life 2: Episode 1 which I just played through again with that setting disabled. Doesn't crash. Enable it, crash within a few minutes.

          Another way to crash is to run piglit tests in parallel. Hard locks it. And it also crashes seemingly on random occasions, but I assume that it's two things doing something at the same time (multithreaded, see what's going on?). This is the reason why I disabled hardware acceleration in my browsers. Much more stable without that.

          So to hopefully help out Shalrath: disable multicore rendering in TF2 and see if works.

          Comment


          • Originally posted by RemcoL View Post

            Has it been a known bug? Yes. But I've had the issue with fglrx, mesa 11 and mesa 12. And it only happens if multicore rendering is enabled. The same crash happens in Half-Life 2: Episode 1 which I just played through again with that setting disabled. Doesn't crash. Enable it, crash within a few minutes.

            Another way to crash is to run piglit tests in parallel. Hard locks it. And it also crashes seemingly on random occasions, but I assume that it's two things doing something at the same time (multithreaded, see what's going on?). This is the reason why I disabled hardware acceleration in my browsers. Much more stable without that.

            So to hopefully help out Shalrath: disable multicore rendering in TF2 and see if works.

            I believe I've tried that before without much luck.. but I'm due for a reboot, so i'll give it another shot

            Strangely enough, I never had the problem with fglrx. Just the fact that fglrx eventually stopped being compatible with Fedora after version 22 or so.

            Comment


            • Originally posted by Shalrath View Post


              I believe I've tried that before without much luck.. but I'm due for a reboot, so i'll give it another shot

              Strangely enough, I never had the problem with fglrx. Just the fact that fglrx eventually stopped being compatible with Fedora after version 22 or so.

              Welp, multicore rendering was disabled, and it still crashed after about 10 minutes.


              It's final words:

              /var/log/messages

              (bunch of these messages beforehand while playing)
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 7) at page 0, read from '' (0x00000000) (200)
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ec802
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E0C8002
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 7) at page 0, read from '' (0x00000000) (200)
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ec802
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E0C8002
              Oct 24 19:43:32 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 7) at page 0, read from '' (0x00000000) (200)

              (here's where it crashed)

              Oct 24 19:43:32 charybdis rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
              Oct 24 19:46:56 charybdis rsyslogd-2177: imjournal: 924186 messages lost due to rate-limiting
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ec802
              Oct 24 19:46:55 charybdis systemd-journald: Missed 876 kernel messages
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C8002
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 5) at page 0, read from '' (0x00000000) (200)
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ac802
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C8002
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 5) at page 0, read from '' (0x00000000) (200)
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ac802
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A0C8002
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: VM fault (0x02, vmid 5) at page 0, read from '' (0x00000000) (200)
              Oct 24 19:46:55 charybdis kernel: amdgpu 0000:01:00.0: GPU fault detected: 147 0x000ac802

              (pages and pages of this)


              And xorg.0.log dumped this at the time of death

              [ 95407.008] [dix] EventToCore: Not implemented yet
              [ 95407.065] [dix] EventToCore: Not implemented yet

              Comment


              • Originally posted by bridgman View Post

                Yep.. the other difference is that drm-next follows the latest WIP kernel code, while amd-staging follows released kernels. It attempts to strike a balance between upstream and the older kernels most of our customers are actually using.
                This is one of the best ideas AMD had. Current stable Kernel with the latest drivers. Brilliant!

                Two questions: Will AMD release the amd-staging-4.8 soon? And will AMD's opensource OpenCL be a part of Mesa-Opencl?

                Cheers

                Comment


                • Originally posted by RemcoL View Post

                  Has it been a known bug? Yes. But I've had the issue with fglrx, mesa 11 and mesa 12. And it only happens if multicore rendering is enabled. The same crash happens in Half-Life 2: Episode 1 which I just played through again with that setting disabled. Doesn't crash. Enable it, crash within a few minutes.

                  Another way to crash is to run piglit tests in parallel. Hard locks it. And it also crashes seemingly on random occasions, but I assume that it's two things doing something at the same time (multithreaded, see what's going on?). This is the reason why I disabled hardware acceleration in my browsers. Much more stable without that.

                  So to hopefully help out Shalrath: disable multicore rendering in TF2 and see if works.
                  This is a complicated bug. For me, disabling multicore accel and setting every graphic option to the lowest doesn't help, and it doesn't happen on FGLRX. What works for me might very well not work for you, for example Debian Jessie with Mesa-11.3 and current libc6 doesn't have the crash, while the same versioning on Arch does.

                  Comment


                  • BTW, the corret/more updated report is this one: https://bugs.freedesktop.org/show_bug.cgi?id=93649

                    Comment


                    • I'll recompile 4.7-staging this morning and see if it got fixed.

                      Comment

                      Working...
                      X