Announcement

Collapse
No announcement yet.

Updated and Optimized Ubuntu Free Graphics Drivers

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

  • Originally posted by 0xBADCODE View Post
    Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around.
    As stated in comment to video I linked it's was only partially reclocked GPU and not reclocked memory, but still had better performance than Nvidia blob. Considering @tizbac done tons of Gallium Nine testing I have no reasons to not trust him.

    Originally posted by 0xBADCODE View Post
    My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.
    We already have Wine and many people use it. Does it hurt if we work a bit better?

    Anyway this is really off-topic and unfortunately I not the guy who able to maintain patches for Mesa because nearly zero of free time. So we might create some other topic for Gallium nine if you want some slow discussion about that.

    ...

    Back on topic. Is LLVM 3.5 bring any improvements at all for LLVM backend of R600g driver or no?

    Comment


    • Originally posted by 0xBADCODE View Post
      Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around. From what I've read from Phoronix, it looks rather pessimistic and I wouldn't count on nouveau for me at all (and I'm not a big fan of blob drivers in opensource systems either). Needless to say, for that reason I prefer Intel GPU on notebook and AMD GPUs on desktop and somesuch (looking forward to get some few powerful opencl based number crunchers on wheels, could be something *really* interesting to try on opensource stack, eh?).


      My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.


      Whatever. I bet DX would never be first class citizen in Linux due to proprietary/vendor locked nature of this API. Which makes it "unwelcome guest" IMO. And if someone wants "windows but opensource", there is already ReactOS. But looking on how crappy it performs 15 years since launch it looks like if not too much devs actually want to be just a mindless followers of MS who blindly reimplemends MS-only proprietary APIs. For these reasons I mostly classify all thsi DX-in-Linux as waste of time. MS would always have advantage as creator of API, so there is no point to even try to beat them. This is battle you can't win for sure.

      Long story short: I think Linux is good enough to have own path, without being "Windows but opensource" or whatever else.



      We want to play our favorite games (art), without the need of proprietary software (player) like Windowz and D3D. To any computer available, not make as buy consoles or x86 without our will. Meaning open resources like OGL and dynamically linked compilation like LLVM-JIT (maybe with persistent cache). No DRM. Same performance, universal play.

      Because we don't have that, we need a compatibility layer (mostly D3D) on Linux, plus a better recompiler like a better Qemu-LLVM or better.

      My main concern for today's D3D on Linux is that a D3D state tracker can be based on an OGL one and can be developed 10 times faster than Wine's translation layer, just with one developer. Only then i measure the native speed. As for availability, i believe with a Gallium patch, a state tracker can be used even with closed drivers, like when you install mesa on Windowz.

      Comment


      • 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?

        Comment


        • 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


                            • Originally posted by artivision View Post
                              Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.
                              If someone could donate a patch that would be a huge step forward.

                              Comment


                              • More updates

                                You may have noticed I added mesa, libdrm and libclc packages also for Ubuntu 14.10/utopic in the PPA.

                                Also, I looked into adding to mesa package the Gallium D3D9 state tracker (gallium-nine). It works fine, however since it has many changes, merging this git tree into mesa master breaks frequently (as of this writing it still has merge conflicts) and I cannot add it in the main PPA which is automatically updated twice a day. So, I set up a test PPA where you can find a mesa snapshot including it here.

                                Comment

                                Working...
                                X