No announcement yet.

Updated and Optimized Ubuntu Free Graphics Drivers

  • Filter
  • Time
  • Show
Clear All
new posts

  • managed to revert smoothly, but problem persists; maybe llvm is the issue?

    solved synaptic issues by basically unmarking dependencies one-by-one (had to do a few of them simultaneously, e.g. wine and wine:i386, but I got it). however, the problem persists. I grabbed the debian version of llvm-3.2, as that's the only other oibaf package that updated around when I started experiencing these problems, and I couldn't find a more stable version in a ubuntu PPA. we'll see what this does...


    • You can revert the whole PPA, see main PPA page.


      • I know, but I don't necessarily want to, as the mesa packages offer major advantages over any PPA other than edgers (which currently has the same llvm, I checked), and last time I tried reverting this PPA it mistakenly pulled out a number of dependencies (including wine and skype) and created a couple hours' work for me, so I'm trying to work around it as much as possible to get stable again.


        • Originally posted by oibaf View Post
          Please report a bug against mesa if it's still an issue. See first post.
          Right, BUT that's exactly where I got stuck a bit...
          1) I'm not really sure if it's MESA bug or kernel parts bug. Maybe both though, i.e. one generates bad commands stream and other fails to recover from that.
          2) I can see it like this:
          - Initially graphic becomes more and more garbled in some game scenes. Textures on objects are looking like random garbage. It's some kind of error as well, but I don't know if these are directly related to lockup.
          - On some scene GPU is getting stuck, picture freezes. Kernel still alive some ~10 seconds though (responds to alt-sysrq requests).
          - Then GPU timeout expires (about 10 seconds or so). Kernel does GPU reset (kernel attempts to reset hanged GPU and recover).
          - Everything hangs. In fact deadlock is so hard that kernel haves no chances to flush disk buffers. So I lack kern.log and unable to see what kind of trouble has occured. Of course it also stops responding to die-hard alt-sysrq combos.
          (as you can guess it's futile and pointless to use gdb in this situation as well).

          I found some ways to reproduce that but they're probablistic and require to spend enough time playing some game and matching dozen and half prerequisites in stateful (RPG) )game and even then it takes from minutes to hours to reproduce. I undertook dozen and half of attempts to collect at least some logs of what's going on but stull was not able to gather any data. Lockup is guaranteed and so hard that it's making it hard to gather any data at that moment. So in fact I can't provide devs with enough info about problem or give them some fast and reliable way to reproduce that. Sounds like a problem to me .

          Right now I decided to try recent 3.9-rc1 kernel. It haves GPU reset reworked. So let's see if there will be lockups and if new reset code will be able to recover from these without hanging. As extra bonus I have unique chance to test new GPU reset code if this problem persists . Right now with 3.9-rc1 kernel system is still alive for some half of hour under excessive attempts to cause lockup. Graphic is moderately garbled (so there are at least some bugs left so far) but deadlock does not occurred so far. OTOH as an extra bonus I've got some rare bug in GPU reclocking code of 3.8 kernel which could also cause lockup. I guess it's worth of filing since I managed to collect at least some data.
          Last edited by 0xBADCODE; 08 March 2013, 03:09 AM.


          • Valve team fortress problem


            in the past, TF2 worked using mesa 9.1 on a ubuntu 12.10... but i was busy for several weeks and now when trying again TF2 crashs on finishing loading the resources (3D related crash)

            i also found that Killing floor game also crashes when loading the map (again 3D crash)

            Does anyone using this drivers have the same problem? or i manage to break my system



            • Intel hd4000 some garbage colors when I try to play Serious Sam BFE3...


              • @oibaf: Now when AMD released UVD VDPAU support in mesa, can you include it into your PPA?
                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


                • Any tips for diagnosing strange slowdowns/lockups in games?

                  I've been trying to play the fairly recently released Linux-native Red Orchestra port on a 5770 with the latest from this PPA, and I'm getting horribly slow framerates (5 fps on average) and resulting serious input lag whenever rendering a 3D scene.

                  Nothing appears to be going off the rails in dmesg's log, and when I start the game via the command line barely any messages are displayed, and the few that are have nothing to do with 3D rendering. The ingame console (engine is based off Unreal 2) does not show any engine info by default or with the commands STAT HARDWARE / STAT RENDER / etc. All references to to debug packages in the OP have to do with crashes, and that is not what I am experiencing. Is running the game with gdb still worth trying without crashes?

                  I'd like to be able to pinpoint the problem and report it, but I'm coming up short in identifying it. Any help is appreciated!


                  • @pali: sure.

                    @CossRooper: send a mail at no subscription required.


                    • Originally posted by oibaf View Post
                      @pali: sure.

                      @CossRooper: send a mail at no subscription required.
                      Very excited for UVD! And thanks for the mailing list tip, I've never used one but I'll give it my best shot.