Announcement

Collapse
No announcement yet.

Upgrading The Linux Kernel, Mesa/X.Org Packages On Ubuntu 14.04

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

  • Upgrading The Linux Kernel, Mesa/X.Org Packages On Ubuntu 14.04

    Phoronix: Upgrading The Linux Kernel, Mesa/X.Org Packages On Ubuntu 14.04

    Upgrading the Linux kernel and Mesa/X.Org graphics driver components past what Canonical shipped in Ubuntu 14.04 LTS and other recent releases of Ubuntu Linux isn't actually that hard... Here's the Phoronix-recommended approach for Linux enthusiasts wishing to upgrade their key software components for yielding better open-source graphics driver performance and features...

    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

  • #2
    Nice guide; I pretty much follow the same process on 3 different computers I own.

    I think oibaf's PPA would be more up-to-date than xorg-edgers though, but generally speaking, the more up-to-date things are, the higher chance of stuff breaking is I guess (the other day I ended up having glamor broken due to some update not liking a dependency).

    I'd be curious on whether to choose generic or lowlatency though. I realize generic is probably fine, but why offer a lowlatency variant too? Most usage scenarios I've heard of in the past for using a low latency kernel was audio-related, but lately, it seems to also be useful for gaming too (I think SteamOS uses either a lowlatency or real-time kernel; openSUSE 13.1 also uses some desktop-optimized kernel with lower latency). Maybe some benchmarks of generic and lowlatency would be nice

    Comment


    • #3
      The problem is, the kernel mainline follows the development release, so very soon there will not be any mainline kernels for trusty.

      For the kernel, I use git to keep it up to date, and compile with a little script I wrote, following an Ubuntu howto:

      Code:
      myRealName@grisell:linux$ more compile-kernel.sh 
      #!/bin/bash
      
      export CFLAGS="-march=native -O2 -pipe"
      export CFLAGS="-march=native -O2"
      export CXXFLAGS="$CFLAGS"
      
      # uncomment this .config copying only if needed
      # cp /boot/config-`uname -r` .config
      
      yes '' | make oldconfig
      make clean
      make -j 8 deb-pkg LOCALVERSION=-myRealName
      Note that this produces .deb packages that I later install (an uninstall as appropriate with Synaptic).

      Comment


      • #4
        Originally posted by mendieta View Post
        The problem is, the kernel mainline follows the development release, so very soon there will not be any mainline kernels for trusty.
        It doesn't matter on what distro version the mainline build was created, they still work the same on older releases. So v3.16.x-unicorn will work just fine on trusty and before.

        Comment


        • #5
          Originally posted by Espionage724 View Post
          ...(the other day I ended up having glamor broken due to some update not liking a dependency)...
          This is exactly why I use aptitude instead of apt. Aptitude is incredible with dependency handling and tells you of any conflicts and offers solutions to them. I had the potential for glamor to break just the other day as well, however aptitude told me of the conflicts and offered a solution to just keep some packages at their current version so it doesn't break the whole system.

          Personally I use the very very very latest Kubuntu. I was on 13.10 days after 13.04 was released, on 14.04 days after 13.10 was released, and will do the same for 14.10. In this entire span of doing this, not once have I had a package dependency problem, thanks to aptitude. Oh, speaking of, I need Oracle JDK6, which currently conflicts with apt 1.0, so aptitude's first solution it offered? Just keep apt at its current version. Besides, it's not like I need the very latest apt!

          EDIT: BTW I do use the mainline kernel repo as well as OIBAF. Previously I had used xorg-edgers but they seem to have lost their touch.
          Last edited by MWisBest; 05 April 2014, 02:28 AM.

          Comment


          • #6
            Originally posted by MWisBest View Post
            *snip* I do use the mainline kernel repo as well as OIBAF. Previously I had used xorg-edgers but they seem to have lost their touch.
            Why do you think they lost their touch?

            Comment


            • #7
              Are that much Ubuntu specific articles really necessary? Honestly?

              Comment


              • #8
                Regarding both PPAs, I want to highlight a few facts:
                - While right now both PPAs compile mesa with LLVM 3.4 (for trusty), Oibaf's PPA will probably be faster in using LLVM 3.5 in the future, if still exists...
                - Only Oibaf's PPA includes OpenCL within mesa.
                - Oibaf has helped developers and others in testing patches and such.
                I guess there are many more differences, but those are the main ones I've found (other than the obvious ones..).

                Comment


                • #9
                  It's not clear why before the release date they cannot upgrade kernel to 3.14 version. If it's so simple, why developers avoid this upgrade? Possible dependencies problems or possible malfunctioning?

                  Comment


                  • #10
                    Originally posted by Azrael5 View Post
                    It's not clear why before the release date they cannot upgrade kernel to 3.14 version. If it's so simple, why developers avoid this upgrade? Possible dependencies problems or possible malfunctioning?
                    Like the article sayes, binery driveres. Also testing and custom patches.

                    Comment

                    Working...
                    X