Announcement

Collapse
No announcement yet.

State of Nouveau now and in the near future?

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

  • State of Nouveau now and in the near future?

    Is Nouveau in a 'usable' state yet? Will it be soon? I replaced my GTX 660 with an AMD card and regret it greatly. I'm probably going to pick up a new 900-series nvidia card shortly, I doubt there will be any Nouveau support but it would be interesting.

  • #2
    Do you plan to use nouveau with your new card? Which card do you own now and why don't you like it?
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

    Comment


    • #3
      Originally posted by darkbasic View Post
      Do you plan to use nouveau with your new card? Which card do you own now and why don't you like it?
      I'd probably use the proprietary drivers because AFAIK nouveau isn't ready yet.
      I own an R9 270, I've had constant issues with it. Currently I'm suffering from random crashes using radeonsi and frequently not waking up properly from suspend. I've tried RC kernels, mesa-git, etc and I always have some sort of issue. I never had anywhere near as many problems with nvidia.

      Comment


      • #4
        Same issue with HD 7950 (a bit softened with 3.17), but never had such problems in the pre 3.15 era. Did you consider running Catalyst until it gets fixed?
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #5
          Originally posted by darkbasic View Post
          Same issue with HD 7950 (a bit softened with 3.17), but never had such problems in the pre 3.15 era. Did you consider running Catalyst until it gets fixed?
          AFAIK I still have to downgrade X to 1.15 to install catalyst which sounds annoying, and catalyst isn't that well supported/stable from my experience. I've had issues ever since I got my AMD card.

          FWIW, I installed 3.17rc6 last night and didn't get any crashes but I didn't test it much. It has some radeon DRM fixes related to crashing. After reviewing the changes real quick I *think* that it's fixed, but I'm not sure, I don't know much about the radeon DRM driver, but the changes seem related.

          Comment


          • #6
            peppercats, is your problem like the one described in bug #78221 on the Linux kernel bug tracker (sorry, can't post URLs yet), i.e...

            Code:
            Jun 18 03:10:01 localhost kernel: [26125.102351] radeon 0000:01:00.0: ring 0 stalled for more than 10263msec
            Jun 18 03:10:01 localhost kernel: [26125.102362] radeon 0000:01:00.0: GPU lockup (waiting for 0x0000000000445274 last fence id 0x0000000000445273 on ring 0)
            [...]
            Jun 18 03:10:24 localhost kernel: [26148.262523] radeon 0000:01:00.0: GPU fault detected: 146 0x05428804
            Jun 18 03:10:24 localhost kernel: [26148.262534] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0000A1AA
            Jun 18 03:10:24 localhost kernel: [26148.262539] radeon 0000:01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02088004
            Jun 18 03:10:24 localhost kernel: [26148.262544] VM fault (0x04, vmid 1) at page 41386, read from TC (136)
            I'm experiencing this particular one on my 270X for quite some time, and it is, indeed, a rather nasty bug: screen goes blank, monitor drops to stand-by, and while the GPU recovers gracefully sometimes, in about half of the cases a hard reset is the only way to bring the system back to life. However, there are two easy workarounds until the bug gets eventually tracked down to its source and patched. You can either put the "radeon.dpm=0" parameter on the kernel command line, which unfortunately will kill the performance in the more demanding 3D applications, or you can set the R600_DEBUG environment variable to "nodma" (depending on your distribution, there might be a different best-practice method of doing this, e.g. on Arch you'd put "R600_DEBUG=nodma" in /etc/environment). The latter method seems to have less impact on performance, though I haven't tested that much, to be honest (and the most demanding game that I run these days is Expeditions: Conquistador, where there's little impact with the first method and none with the second).

            HTH,
            Luchesar

            P.S. My previous card was an NVIDIA, and their proprietary driver is indeed very, very good. But if you want to stay with the open source drivers, then AMD seems like the better choice. I was actually very pleasantly surprised by the performance and quality of Metro: LL -- probably the most demanding game in my collection of Linux games -- running on radeonsi: haven't measured the framerate, but the game was running smoothly with practically no visual artefacts (the only one I've noticed, if I remember correctly, was some barely noticeable tint in some specific shadows).

            Comment


            • #7
              I'm tired of this whole thing: prior to 3.15 radeon was the most stable driver ever and now it seems to use Windows 95
              ## VGA ##
              AMD: X1950XTX, HD3870, HD5870
              Intel: GMA45, HD3000 (Core i5 2500K)

              Comment


              • #8
                Originally posted by darkbasic View Post
                I'm tired of this whole thing: prior to 3.15 radeon was the most stable driver ever and now it seems to use Windows 95
                Indeed, that specific bug seems to had been manifesting itself much less frequently before 3.16 (it was for this reason suspected to be a regression in 3.16, until the guy from the bug report managed to reproduce it also in 3.15, albeit 'it takes "almost forever" to crash it with previously used methods', as he/she notes). Unfortunately, things like this are inevitable in the present state of rapid development with a relatively modest resources behind it. But don't forget that it's also our responsibility -- as users -- to help the developers pinpoint the problems. And at least to me this is actually more satisfying and even exciting than just using some already polished, but proprietary driver (or any piece of software, for that matter).

                Comment


                • #9
                  I like testing the drivers but I hate stability issues, I use my system to work and if it becomes unstable I have to switch to proprietary drivers so no testing.
                  ## VGA ##
                  AMD: X1950XTX, HD3870, HD5870
                  Intel: GMA45, HD3000 (Core i5 2500K)

                  Comment


                  • #10
                    Originally posted by darkbasic View Post
                    I like testing the drivers but I hate stability issues, I use my system to work and if it becomes unstable I have to switch to proprietary drivers so no testing.
                    I totally agree with you here. Then again, this has also been the only problem I've encountered so far that interfered with my work, as opposed to leisure activities (read: gaming). And, again, there is a reasonably good workaround, although I have to admit that it did take some time to research it (and that's why I decided to share it here). Overall, I think, AMD is doing pretty good job with the open-source driver. It'll probably take many more months for the dust to settle down completely, but even now the driver is more than good enough for most people, and even for some/many gamers -- at least that has been my personal experience with an R9 270X -- though for the games in particular, mesa-git still is most likely a must (and LLVM 3.5+ too).

                    Comment

                    Working...
                    X