Announcement

Collapse
No announcement yet.

GeForce GTX 970/980 Linux Benchmarks With NVIDIA 346.16 Driver

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

  • GeForce GTX 970/980 Linux Benchmarks With NVIDIA 346.16 Driver

    Phoronix: GeForce GTX 970/980 Linux Benchmarks With NVIDIA 346.16 Driver

    This week NVIDIA introduced the 346 Linux driver beta with a huge amount of changes and new features -- from GPU over-volting to NVENC and VP8 support. Curiosity got the best of me so I've now ran some GeForce GTX 970 and GTX 980 Linux benchmarks to see if the performance of these new, high-end Maxwell GPUs have changed at all with this latest proprietary driver release...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Seems to me like more and more tests are CPU limited with newer GPU's?

    Comment


    • #3
      Michael is there a way of benchmarking accelerated video performance (encoding decoding etc)?

      Comment


      • #4
        pcie errors

        Michael,

        This is a long shot, but in your testing do you see any PCIE errors such as these?

        dmesg
        ...
        [ 7411.725766] pcieport 0000:00:02.0: AER: Multiple Corrected error received: id=0010
        [ 7411.725774] pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0010(Receiver ID)
        [ 7411.725777] pcieport 0000:00:02.0: device [8086:2f04] error status/mask=00000001/00002000
        [ 7411.725779] pcieport 0000:00:02.0: [ 0] Receiver Error (First)

        I've had these issues with both 343.22 and 346.16.

        I've done some googling and it seems I'm not the only Linux user of an X99 chipset board to have these issues with Nvidia GPU's (the GPU model doesn't seem to matter, but I have a GTX 980). My motherboard is the Asus Rampage V Extreme, and I've seen others have this issue with the EVGA X99 Classified.

        In spite of these errors, my system is stable if I use it even with compositing, but will crash if I let it idle using a 3d accelerated screensaver.

        It seems Windows users were also having this issue (with errors relating to 8086:2f04), but I'm fine in Windows. Maybe this issue is fixed in the Nvidia drivers for Windows? I'm in Linux 99.9% of the time regardless.

        It seems to be related to Nvidia cards and PCIE 3.0 support. Maybe I need to wait for a BIOS update

        Comment


        • #5
          Prime95 for a while, especially if you have an overclock. Your system may act stable, but it might put single-bit errors in weird places regardless.

          Comment


          • #6
            Originally posted by A Laggy Grunt View Post
            Prime95 for a while, especially if you have an overclock. Your system may act stable, but it might put single-bit errors in weird places regardless.
            I've never used Prime95. I assume it's a windows program?

            Anyway, I'm definitely not overclocking. A lot of the other people who have experienced this problem, haven't been overclocking either.

            Comment


            • #7
              Originally posted by hiryu View Post
              Michael,

              This is a long shot, but in your testing do you see any PCIE errors such as these?

              dmesg
              ...
              [ 7411.725766] pcieport 0000:00:02.0: AER: Multiple Corrected error received: id=0010
              [ 7411.725774] pcieport 0000:00:02.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0010(Receiver ID)
              [ 7411.725777] pcieport 0000:00:02.0: device [8086:2f04] error status/mask=00000001/00002000
              [ 7411.725779] pcieport 0000:00:02.0: [ 0] Receiver Error (First)

              I've had these issues with both 343.22 and 346.16.

              I've done some googling and it seems I'm not the only Linux user of an X99 chipset board to have these issues with Nvidia GPU's (the GPU model doesn't seem to matter, but I have a GTX 980). My motherboard is the Asus Rampage V Extreme, and I've seen others have this issue with the EVGA X99 Classified.

              In spite of these errors, my system is stable if I use it even with compositing, but will crash if I let it idle using a 3d accelerated screensaver.

              It seems Windows users were also having this issue (with errors relating to 8086:2f04), but I'm fine in Windows. Maybe this issue is fixed in the Nvidia drivers for Windows? I'm in Linux 99.9% of the time regardless.

              It seems to be related to Nvidia cards and PCIE 3.0 support. Maybe I need to wait for a BIOS update
              Hiryu,

              Funny, I just started a thread discussing these PCIe errors. Did you ever find a resolution? I have a ASRock X99 Extreme11 board with GTX 980 SC and I'm seeing the exact same errors you describe. Passing "pci=nomsi" and going back to legacy interrupts seems to make the errors go a way, but I don't think this is optimal.

              Have you found any progress on this issue?

              Comment


              • #8
                Originally posted by BLinux View Post
                Hiryu,

                Funny, I just started a thread discussing these PCIe errors. Did you ever find a resolution? I have a ASRock X99 Extreme11 board with GTX 980 SC and I'm seeing the exact same errors you describe. Passing "pci=nomsi" and going back to legacy interrupts seems to make the errors go a way, but I don't think this is optimal.

                Have you found any progress on this issue?
                Where did you start the thread? Here on Phoronix?

                Anyway, now that I've been able to use my comp some more since I made my original post, I've found that my system ISN'T stable with this issue. My box might stay up 5 minutes or 12 hours. The stability of the box is _partially_ related to whether or not I run anything that uses 3d acceleration. I've found that I don't have to reboot my box when I get up in the morning if I use a non-OpenGL screensaver. Even then it's not necessarily a hard lock. I can often ssh in and force a reboot that way.

                However, I've found that when I boot up, the amount of these errors I see can vary pretty widely. If I see a ton of errors before I even get to the login manager, there's a good chance the box won't last long. I haven't seen my box lock up when there's very few errors (usually I'm somewhere in between, however).

                The problem seems somewhat random, but I think I may have found a shitty work around within the last few days. It may be that when I boot into windows first (I very rarely use windows ever, which is why it took me a while to notice this), and then do a soft reboot into Linux, it may be that this does a lot to fix the issue. In my last test run, I only saw errors every hours(!!!) when typically in the best case I see them every few minutes. But I haven't thoroughly tested this yet to see if this is always or almost always true when booting into Windows first. I'll try to test it more this weekend (I've been on-call this week, so no time).

                If you have windows, you might give it a shot as well.

                I have some personal precedent with this sort of thing too. Years ago, when I had a brand new Radeon 9800, I had a similar issue. The fglrx drivers (this was around 2003-2004) wouldn't work in linux at all (linux would lock up as soon as X would try to start) unless I booted into Windows first.

                Comment


                • #9
                  Originally posted by hiryu View Post
                  Where did you start the thread? Here on Phoronix?
                  yes, here: http://www.phoronix.com/forums/showt...x-with-GTX-980

                  Originally posted by hiryu View Post
                  Anyway, now that I've been able to use my comp some more since I made my original post, I've found that my system ISN'T stable with this issue. My box might stay up 5 minutes or 12 hours. The stability of the box is _partially_ related to whether or not I run anything that uses 3d acceleration. I've found that I don't have to reboot my box when I get up in the morning if I use a non-OpenGL screensaver. Even then it's not necessarily a hard lock. I can often ssh in and force a reboot that way.

                  However, I've found that when I boot up, the amount of these errors I see can vary pretty widely. If I see a ton of errors before I even get to the login manager, there's a good chance the box won't last long. I haven't seen my box lock up when there's very few errors (usually I'm somewhere in between, however).

                  The problem seems somewhat random, but I think I may have found a shitty work around within the last few days. It may be that when I boot into windows first (I very rarely use windows ever, which is why it took me a while to notice this), and then do a soft reboot into Linux, it may be that this does a lot to fix the issue. In my last test run, I only saw errors every hours(!!!) when typically in the best case I see them every few minutes. But I haven't thoroughly tested this yet to see if this is always or almost always true when booting into Windows first. I'll try to test it more this weekend (I've been on-call this week, so no time).

                  If you have windows, you might give it a shot as well.

                  I have some personal precedent with this sort of thing too. Years ago, when I had a brand new Radeon 9800, I had a similar issue. The fglrx drivers (this was around 2003-2004) wouldn't work in linux at all (linux would lock up as soon as X would try to start) unless I booted into Windows first.
                  well, in my case, giving the linux kernel the pci=nomsi gets rid of the error message and my system has been stable. i haven't run it without the pci= option to see if it causes instability. unfortunately, i do not have windows anymore to try your suggestion. does your system stablize if you use the pci=nomsi option?

                  Comment


                  • #10
                    Originally posted by hiryu View Post
                    Where did you start the thread? Here on Phoronix?

                    Anyway, now that I've been able to use my comp some more since I made my original post, I've found that my system ISN'T stable with this issue. My box might stay up 5 minutes or 12 hours. The stability of the box is _partially_ related to whether or not I run anything that uses 3d acceleration. I've found that I don't have to reboot my box when I get up in the morning if I use a non-OpenGL screensaver. Even then it's not necessarily a hard lock. I can often ssh in and force a reboot that way.

                    However, I've found that when I boot up, the amount of these errors I see can vary pretty widely. If I see a ton of errors before I even get to the login manager, there's a good chance the box won't last long. I haven't seen my box lock up when there's very few errors (usually I'm somewhere in between, however).

                    The problem seems somewhat random, but I think I may have found a shitty work around within the last few days. It may be that when I boot into windows first (I very rarely use windows ever, which is why it took me a while to notice this), and then do a soft reboot into Linux, it may be that this does a lot to fix the issue. In my last test run, I only saw errors every hours(!!!) when typically in the best case I see them every few minutes. But I haven't thoroughly tested this yet to see if this is always or almost always true when booting into Windows first. I'll try to test it more this weekend (I've been on-call this week, so no time).

                    If you have windows, you might give it a shot as well.

                    I have some personal precedent with this sort of thing too. Years ago, when I had a brand new Radeon 9800, I had a similar issue. The fglrx drivers (this was around 2003-2004) wouldn't work in linux at all (linux would lock up as soon as X would try to start) unless I booted into Windows first.
                    Not that this is gonna help any, but I once had a wifi adapter that I had to boot into windows first then reboot into linux before it would work. The linux driver was putting it into some kind of an unusable state, which the windows driver apparently was able to reset.

                    As far as the error message you are receiving goes, it sounds to me like the PCIe controller (or the driver which controls the buss) implements some functionality the graphics card doesn't support, which is being interpreted by the driver as buss errors.

                    Just a guess, I really don't know.

                    Comment

                    Working...
                    X