Announcement

Collapse
No announcement yet.

Major Performance Breakthrough Discovered For Intel's Mesa Driver

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

  • #21
    Originally posted by FutureSuture View Post
    If you think that is dysfunctional, then head on over to AMD. How many drivers for Linux will AMD be maintaining? 1? 2? 3? I am not even sure now. I wish Valve would spend its own money to hire a third party developer to aid AMD. Competition is good but AMD needs some help in that department.
    AMD has only FGLRX now. They are merging FGLRX and opensource into a binary driver. Firepro driver are pretty much FGLRX.

    Comment


    • #22
      Originally posted by johnc View Post
      So the Intel Linux driver team couldn't just pick up the phone and ask their Windows driver team counterpart about the performance differences? Valve had to spend its own money to hire a third-party developer to investigate the issue?

      Intel strikes me as a completely dysfunctional company.
      I doubt they even knew where to look - LunarG narrowly scoped/reproduced the problem with their tests to the point where Intel would be able to fix it.

      To your point, it's not so much dysfunction as it is lack of interest in ensuring both drivers for windows and Linux are on par. There is no reason why they should not be. It's definitely a black eye for Intel to have a 3rd party vendor identify major gaps between their drivers like this. If I were a manager at Intel, right about now I'd ask that whatever test suites they use to prove out the Windows' driver performance be completely ported over to Linux to test their Mesa driver. Anything short of this feels like they are merely placating the open source community/developers.

      Comment


      • #23
        Originally posted by smitty3268 View Post
        After all this time, there's still not one person who's bisected the regression.
        Hard to bisect something that takes 5 minutes to 3 days to arise. I am the OP to bug 61844 for Mesa's RadeonSI random crashes. Why don't you go ahead and bisect it for me over an entire month, even if it is because of a single commit? Be reminded it's not known clearly to be Mesa, or a kernel update that shows it, or anything else. I personally think it's DMA issues of some sort, but I'm also not a kernel/AMD dev. Still, besides this bug for me, RadeonSI is fine on my R9 270X. But this bug is bad. And it's been a problem for about 3 months now. Other than that, most games run fine with everything on Ultra: Civ 5, The Witcher, tons of valve games. Rust has major engine issues with it being a POS, but most games programmed well are just fine.

        Comment


        • #24
          Originally posted by zanny View Post
          I have a 7870, I've used 6000 series cards, and I've built and run 3 r600 / radoensi APUs. The only time radeonsi ever crashes is in extremely new games, and very rarely, but example I got one crash in ~80 hours of borderlands 2 and it was due to a firmware bug on the card that got fixed a week later.

          Catalyst, on the other hand, is lucky to last an afternoon.
          Don't you dare. You have no idea WTF you're talking about and Darkbasic is 100% correct. Ever since Linux 3.14 and the new radeonsi firware there is a random crash bug that hasn't been fixed so you either have an old kernel or a older linux firmare (that technically was 600) or are lying. I had to go back to catalyst for stablity (which hasn't crashed once).

          Comment


          • #25
            Originally posted by gigaplex View Post
            I had a look through that bug report. It quickly devolved into a dumping ground of "me too" reports of unrelated issues. They couldn't get a clear, consistent answer on which kernels were actually affected, so where would the bisection start?
            greater than 3.14-2 anyhow it's been bisected many times but it's proven to be very hard to peg down also the complete lack of detail in the crash report basically tells you nothing. I feel like donating my 7870 to Michael if he would bisect the fuck out of the kernels for a while maybe he can track it down he has found a power regression that was illusive.

            Comment


            • #26
              Originally posted by souenzzo View Post
              meanwhile, in nVidia....
              GeForce 7025 still not work with Nouveau (full system crash) and work unstable with nVidia 304xx...
              The same with a Nvidia 6100 Go Laptop

              Comment


              • #27
                Originally posted by johnc View Post
                So the Intel Linux driver team couldn't just pick up the phone and ask their Windows driver team counterpart about the performance differences? Valve had to spend its own money to hire a third-party developer to investigate the issue?

                Intel strikes me as a completely dysfunctional company.
                My thoughts exactly. Do they hire the cheapest newbies to work on their Linux driver or what? "it's open source so you can learn as you go along, or ask the community for help"

                Then came a company who actually cares and hires someone who has a clue, and they end up pointing out: guys, you forgot the handbrake on.

                Comment


                • #28
                  Originally posted by nightmarex View Post
                  Don't you dare. You have no idea WTF you're talking about and Darkbasic is 100% correct. Ever since Linux 3.14 and the new radeonsi firware there is a random crash bug that hasn't been fixed so you either have an old kernel or a older linux firmare (that technically was 600) or are lying. I had to go back to catalyst for stablity (which hasn't crashed once).
                  Easy now guys. The truth is that the FGLRX is stable for some cards/games, but unstable for others ... the FOSS drivers are also stable for some, but not for others. If you read the forums enough you'll notice that.

                  I myself hadn't had a problem with the radeon driver for maybe 3 or 4 years, but I didn't game much with it.

                  Comment


                  • #29
                    Originally posted by jaxxed View Post
                    Easy now guys. The truth is that the FGLRX is stable for some cards/games, but unstable for others ... the FOSS drivers are also stable for some, but not for others. If you read the forums enough you'll notice that.

                    I myself hadn't had a problem with the radeon driver for maybe 3 or 4 years, but I didn't game much with it.
                    I think the Intel Linux driver guys don't benchmark against the Windows driver. But they run benchmarks against themselves, to track performance changes.

                    And then there are the AMD guys who don't (have time to) benchmark at all.

                    My guess is, if you want performance to match the Windows driver you will have to figure out it by yourself, like the Lunar guys did.

                    Comment


                    • #30
                      Originally posted by TheAaronB123 View Post
                      Hard to bisect something that takes 5 minutes to 3 days to arise. I am the OP to bug 61844 for Mesa's RadeonSI random crashes. Why don't you go ahead and bisect it for me over an entire month, even if it is because of a single commit? Be reminded it's not known clearly to be Mesa, or a kernel update that shows it, or anything else. I personally think it's DMA issues of some sort, but I'm also not a kernel/AMD dev. Still, besides this bug for me, RadeonSI is fine on my R9 270X. But this bug is bad. And it's been a problem for about 3 months now. Other than that, most games run fine with everything on Ultra: Civ 5, The Witcher, tons of valve games. Rust has major engine issues with it being a POS, but most games programmed well are just fine.
                      If there's a guaranteed non-interactive reproducer and someone's willing to lend a machine for a longer period of time or so, probably not hard to script automated bisecting

                      Comment

                      Working...
                      X