Announcement

Collapse
No announcement yet.

Updated and Optimized Ubuntu Free Graphics Drivers

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

  • Originally posted by starcrossed View Post
    Hey. Long time Linux user but new to the desktop stack / Xorg etc...

    I picked up a new Lenovo Z50 with the AMD A10-7300 Kaveri because I wanted to check out the new HSA features. I installed Ubuntu 14.04 on it and so far everything has gone smoothly (altho I had to boot "nomodeset nolapic").

    One problem was that X was running with a software renderer so I tried installing the PPA radeonsi drivers but nothing changed. I'm not sure if my problem is that the chip is too new, or if I did something wrong, but since I've never done this before and don't have any understanding about how Xorg/Gallium/PPA all fit together I'm not sure how to debug this.

    Any guidance would be appreciated.

    Here's the Xorg.0.log.

    https://gist.github.com/orionz/1d16b1f7a7aafa5242c8

    And here's glxinfo

    Code:
    $ glxinfo | grep OpenGL
    OpenGL vendor string: VMware, Inc.
    OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
    OpenGL version string: 3.0 Mesa 10.3.0-devel (git-fb237ba trusty-oibaf-ppa)
    OpenGL shading language version string: 1.30
    OpenGL context flags: (none)
    OpenGL extensions:
    Have you checked if glamor (xserver-xorg-glamoregl and libglamor) is installed?

    Comment


    • Originally posted by starcrossed View Post
      I picked up a new Lenovo Z50 with the AMD A10-7300 Kaveri because I wanted to check out the new HSA features. I installed Ubuntu 14.04 on it and so far everything has gone smoothly (altho I had to boot "nomodeset nolapic").
      nomodeset disables the driver. remove that otherwise the driver won't load.

      Comment


      • Updates

        Some recent updates:
        • added some updated packages (vaapi library and intel driver, mesa-utils 8.2, libvdpau);
        • mesa now uses megadrivers also for gallium drivers, this saves many MB in the packages;
        • ubuntu 13.10/saucy reached end of life, packages for it cannot be provided anymore.
        About llvm 3.5 I know it's available, unfortunately the building on launchpad fails because it requires more hard disk space on the building machine, see the build log in my test PPA:
        https://launchpad.net/~oibaf/+archiv...+build/6206038

        This looks a known issue:
        https://answers.launchpad.net/launch...uestion/247839

        Once this get fixed I'll upload llvm 3.5 and build mesa against it.

        Comment


        • Originally posted by oibaf View Post
          Some recent updates:[LIST]
          About llvm 3.5 I know it's available, unfortunately the building on launchpad fails because it requires more hard disk space on the building machine, see the build log in my test PPA:
          https://launchpad.net/~oibaf/+archiv...+build/6206038

          This looks a known issue:
          https://answers.launchpad.net/launch...uestion/247839

          Once this get fixed I'll upload llvm 3.5 and build mesa against it.
          If that is a problem why don't you try just disabling building debug packages temporarily for example .

          Comment


          • Originally posted by dungeon View Post
            If that is a problem why don't you try just disabling building debug packages temporarily for example .
            This is also an alternative, if someone do it I can then copy it in my PPA.

            Comment


            • Did you look at Pali's PPA packages? As i see he maintain daily graphics packages for Precise only, but he has llvm-3.5 builded for both i386/amd64... some debian snaphot from last month based, that is better then 3.4 .

              https://launchpad.net/~pali/+archive...aphics-drivers

              Comment


              • Originally posted by agd5f View Post
                nomodeset disables the driver. remove that otherwise the driver won't load.
                This was it! I had to compile a kernel from git head in order to get it to boot without nomodeset but now everything is working great. =)

                Thanks!

                Comment


                • Not sure if there would be much demand for it, but what about also including an updated xserver package (preferably from git, but 1.16 is stable; I think 1.15.1 is latest in Trusty)? A few notable changes with it is the integrated glamor support, along with improved performance.

                  Comment


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

                    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.

                      Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.

                      Comment


                      • Originally posted by artivision View Post
                        Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.
                        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.

                        Comment


                        • Trouble on the way...

                          There is some trouble on the way. It comes to OpenCL - the dependencies are now not fully correct.

                          Updated stack brought LLVM-3.5 and most driver part are now built agains LLVM 3.5, making LLVM 3.4 mostly obsolete.

                          However, mesa-opencl-icd package from your PPA depends on at least ocl-icd-libopencl1 and libclc-r600 which are NOT provided by your PPA. Ancient system versions of these packages are used instead (about half year old).
                          Thats where we have trouble on the way (obsoleted) libclc-r600 depends on (obsoleted) libclang-common-3.4-dev (and also on ancient libclc-dev). So OpenCL stack would NOT use brand-new 3.5-rc, which is pity since LLVM 3.4 is totally broken in this regard.

                          What worse, dependencies are not fully correct at this point. It is now perfectly possible to purge libclang1-3.4 (not referenced by other packages). This however would break OpenCL to degree it cant build OpenCL programs.

                          Needless to say, programs using opencl can face nuclear fallout in strange ways:
                          Code:
                          [2014-07-26 22:02:26] In file included from <built-in>:296:
                          In file included from <command line>:7:
                          In file included from /usr/include/clc/clc.h:18:
                          /usr/include/clc/clctypes.h:3:10: fatal error: 'stddef.h' file not found
                          ???Segmentation fault
                          I do think you may want to build ocl-icd-libopencl1, libclc-r600 and libclc-dev packages against LLVM 3.5 and appropriate versions of each other? Sorry for some extra work :\.

                          P.S. and as for MESA DX state tracker: what practical use of it? Wine does not relies on it and it's not like if there were some DX apps built for Linux. So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.
                          Last edited by 0xBADCODE; 07-26-2014, 02:38 PM.

                          Comment


                          • Originally posted by 0xBADCODE View Post
                            P.S. and as for MESA DX state tracker: what practical use of it?
                            As example @tizbac answered me on YouTube that with Gallium-Nine and Nouveau he have better performance in GTA4 than in Nvidia blob and WineD3D. So I suppose it's can be interesting experiment.

                            Originally posted by 0xBADCODE View Post
                            Wine does not relies on it and it's not like if there were some DX apps built for Linux.
                            As far as I get Wine patch that required to support it isn't that big at all.
                            Patched Wine can be easily distributed with something like PlayOnLinux.

                            Originally posted by 0xBADCODE View Post
                            So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.
                            No it's not abandoned. There is repo it's recently merged into recent Mesa:
                            https://github.com/iXit/Mesa-3D/commits/master
                            And some guys still around on #d3d9 IRC on freenode.

                            PS: I didn't yet made any test of current version so I can't say in what state it is.
                            Last edited by _SXX_; 07-26-2014, 02:52 PM.

                            Comment


                            • Quick update: its possible to fix OpenCL without Oibaf by installing libclang1-3.5 package manually. Then LLVM 3.5 seems to be used - it improves things vs 3.4 heck a LOT.

                              Comment


                              • Originally posted by _SXX_ View Post
                                So I suppose it's can be interesting experiment.
                                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?).

                                As far as I get Wine patch that required to support it isn't that big at all.
                                Patched Wine can be easily distributed with something like PlayOnLinux.
                                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.

                                No it's not abandoned. There is repo it's recently merged into recent Mesa:
                                https://github.com/iXit/Mesa-3D/commits/master
                                And some guys still around on #d3d9 IRC on freenode.
                                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.
                                Last edited by 0xBADCODE; 07-26-2014, 03:16 PM.

                                Comment

                                Working...
                                X