Announcement

Collapse
No announcement yet.

Updated and Optimized Ubuntu Free Graphics Drivers

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

  • Originally posted by oibaf View Post
    Mesa is built with llvm 3.5 now.
    I don't plan to upload newer xorg, it would require to rebuild many drivers, the advantages are not enough.
    I just want to say - thanks for great work man

    Comment


    • Originally posted by oibaf View Post
      I pushed an updated libclc (current git), now also built with llvm-3.5. Mesa is rebuilding now. Please try it in a hour or so.
      BTW, which OpenCL applications do you use? Are them applications in Ubuntu archive or external apps?
      Ahh, I see, libs updated - now it seems to be correct from logical point of view.

      Yet, I wouldn't call LLVM3.5 perfect. Now it can build and run kernels where previous versions failed. Unfortunately, its not a big win in many cases. Because it turned out GPU memory intensive workloads (these which heavily use VRAM) tend to cause funny GPU crashes.

      As for what apps I'm giving a try: various. Some examples could be:
      1) BFGMiner (git repo with most recent version can be found at https://github.com/luke-jr/bfgminer.git). Powerful and funny program with ton of options and relatively big opencl kernels. It got some basic support of MESA. SHA256 bruteforce is mostly about massive parallel computations while scrypt bruteforce is example of GPU memory-heavy workload.
      Current status (with 3.15 and 3.16-rc6 kernels, does not affects things too much): SHA256 - works and computes correctly on both R9 270 (GCN) and HD5770 (VLIW). And even gives about 80% of proprietary driver speed - nice start, isn't it? Though its mostly interesting as testcase/benchmark since ASICs would beat GPUs at SHA256 way too much. Earlier stack had issues building scrypt kernels due to LLVM register allocation failures. Now it can build these kernels. Unfortunately, its not a big win to the date: being memory intense workload, it quickly crashes any GPU, be it VLIW based HD5770 or GCN based R9 270. Just launch it with --benchmark --scrypt and enjoy by GPU deadlock in matter of ~30 seconds. I think AMD guys should use that scrypt bench as some standard testcase or so .

      2) Clinfo. Interestingly, clinfo supplied by Ubuntu/Debian does not works at all, giving obscure error message: E: -30 if you try it with MESA/LLVM stack. That's FAIL but I'm not sure on who's side it happens. However, there're some more informative and more reliable tools like https://github.com/Oblomov/clinfo.git - this one works, verbose enough to give me idea where something breaks and seems to provide more or less correct info about GPUs, matching their specs. It also builds simple kernel as well and if something totally broken, its really nice place to start as it would give adequate idea what fell apart.

      3) Clpeak (can be found at https://github.com/krrishnarraj/clpeak.git). Normally it supposed to be just some GPU VRAM benchmark. While it sounds simple... it tends to crash GPUs a lot during tests. Most notably, I *never* managed to get a single pass on GCN based GPUs at all. I can suggest this one as another testcase for regular use by AMD guys . Seriously, just launch it and enjoy by failry quick GPU deadlock. Especially on GCN GPUs. Not sure why it should work so bad while other workloads like 3D games can run for hours if not days.

      4) "OpenCL examples" - by AMD (get at git://people.freedesktop.org/~tstellar/opencl-example). Basically what it tells - some relatively simple examples, by AMD guy. Mostly working, though get-global-id and get-global-id-3d just crash with segfault.

      Also I have ideas to try some more things in near future. For example, Cryptohaze can be interesting to try, but it complicated app and I think MESA+LLVM should rather get more basic things working first before trying something like this. Now it looks like major issue are memory-heavy workloads - they all tend to crash GPUs and then GPU recovery usually fails to deal with it . So if someone about to try mentioned tools, don't forget to save files and sync filesystem first...

      On side note I can also admit some funny stuff with access rights if you have more than 1 GPU in your system and some GPU(s) are "headless". In system with 2 * HD 5770 you can only see and use both if you running app as root. Else, current user only can see GPU which displays his desktop. To make things more funny, access rights on /dev/dri/card* are handled in really strange way. User should have its primary group set to "video" to be able to deal with these. Else user faces "access denied", even if user has been added to "video" group (so "video" is supplementary group for that user but primary group is something else, traditionally it would be group matching user name). Adding supplementary groups works for normal files but when it comes to /dev/dri/card*, kernel seems to only care about main group of user and not cares about supplementary groups at all, unlike happens with normal files. And even if you strace and get idea about it... then it turns out some ioctls still fails with access denied, too. And this prevents GPUs from being detected. So to use some "headless" GPU you have to run app as root. Which is not the best idea ever, obviously. I think rights handling on /dev/dri/card* is a kernel-side bug? Not sure why card* device rights should be treated in totally different way than usual file access rights. How the heck unprivileged user can use GPUs other than one displaying desktop and how to do it properly without launching everything as root? Just curious how it supposed to work.

      Comment


      • @oibaf: thank you very much

        Comment


        • Hello all,

          Oibaf, thank you for your work.

          Is there a documentation somewhere to compile Mesa into a set of .debs such as in your PPA?

          Since the Oibaf PPA moved onto Mesa 10.3-git, I've experienced important stability issues -- Xorg freezes and crashes, mainly. Mesa 10.1 such as ships with Ubuntu 14.04, has a bug where the Minecraft modpack I mostly play these days grows slower and slower until it's unplayable.

          I would therefore like to compile Mesa 10.2, which worked well for me back when the Oibaf PPA was based on it, into a set of Oibaf-like .debs. Is there a documentation somewhere to do that?

          Thanks.

          Comment


          • @Sundance

            Generally you need packaging knowledge:

            https://www.debian.org/doc/manuals/m...t-guide.en.pdf

            That may sound hard, but all books firstly sounds hard... but you obviusly will need sometimes knowledge from there .

            There are simplified guides, firstly you can try to rebuild some package:

            https://wiki.debian.org/BuildingAPackage

            Or maybe try this more simplified, but right to the matter if you wanna rebuild packages only for you:

            http://raphaelhertzog.com/2010/12/15...bian-packages/

            So there is mesa 10.2 in utopic, can you backporting it for trysty using this guide? It is easy

            http://packages.ubuntu.com/utopic/libgl1-mesa-glx

            http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git

            Of course you may want to have your own PPA and to build there, that is also easy after *knowing* some of those things .
            Last edited by dungeon; 07-27-2014, 03:01 PM.

            Comment


            • @0xBADCODE
              Make sure to report the bugs, maybe they can be fixed before final llvm 3.5.

              @Sundance
              It would be better to report the current problems you have here: https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa so that they can be fixed.
              You may also found older version of packages you downloaded (unless you cleaned the cache) in /var/cache/apt/archives .

              Comment


              • Yeah, filling a bug is the best way to your usage case may continue to work. And there can be a bugs along the way

                @Sundance

                For example, current 10.2 git does not build against current llvm 3.5 . Patch is included in git head:

                http://cgit.freedesktop.org/mesa/mes...90b0cd85e3d3a6

                But not included in mesa 10.2, so you may request that to be included, just point out that on mesa-stable list:

                http://lists.freedesktop.org/mailman...fo/mesa-stable

                Comment


                • Originally posted by oibaf View Post
                  I don't have time to look into this now. If someone is interested and has a working patch can post it here, I could eventually add it to the ppa.
                  Hey, I got pointed to you message from here

                  If you want, there is patch against today git download.ixit.cz/d3d9/ for building libd3dadapter9.so mesa has to be passed "--enable-nine" to ./configure.

                  I hope it helps

                  Comment


                  • Originally posted by okias View Post
                    Hey, I got pointed to you message from here

                    If you want, there is patch against today git download.ixit.cz/d3d9/ for building libd3dadapter9.so mesa has to be passed "--enable-nine" to ./configure.

                    I hope it helps
                    Thanks, I meant a patch against debian dir, but there are docs so I can do it myself.
                    For the nine code I prefer a git branch, I tried https://github.com/iXit/Mesa-3D but fails to merge to current vanilla mesa git due to latest changes.

                    Comment


                    • Hi oibaf, hi dungeon,

                      Thank you for your replies!

                      Yeah, the apt cache is where I first went when things started getting hairy stability-wise. The 10.2 packages were long gone, however. For a while, I've used homemade scripts to freeze the currently installed Mesa packages in place and only upgrade in case of crashes with the current set, but no set of packages have been crash-free so far.

                      In the meanwhile, I got a hard freeze just yesterday, even though I had already downgraded to the default Mesa 10.1 from stock Ubuntu. I suspect the kernel (3.15.6-031506-generic from the mainline repository), this time.

                      The thing is -- this box isn't just for running Minecraft. I also, and mainly, telecommute from here. So stability is pretty darn important. That rules out running an unstable development version of the graphics stack in the long term, which is the core motivation behind my initial request.

                      You're perfectly right about reporting bugs. The main reason I haven't done that so far (sorry!) is, I can't specifically tell how to reproduce them (they're sporadic), and the tracebacks in Xorg.log are from one mieqEnqueue which loudly pleads Not Guilty for the hang/freeze/crash, and from there I don't know what to usefully report. Pointers about that would be nice. Would installing the debug symbols for the relevant packages and chucking the pre-croak Xorg.log at the Mesa people be sufficiently of help?

                      Meanwhile, I think I'll sigh mournfully and go back to stock Ubuntu Mesa on top of stock Ubuntu kernel. Backporting Utopic Mesa stuff sounds like a workable idea, I'll look into that. Thanks all.

                      Comment

                      Working...
                      X