Page 1 of 2 12 LastLast
Results 1 to 10 of 15

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,133

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

    http://www.phoronix.com/vr.php?view=MTY1NTU

  2. #2
    Join Date
    Sep 2013
    Posts
    228

    Default

    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

  3. #3
    Join Date
    Apr 2009
    Posts
    563

    Default

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

  4. #4
    Join Date
    Mar 2010
    Posts
    30

    Default

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

  5. #5
    Join Date
    Dec 2012
    Posts
    97

    Default

    Quote 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; 04-05-2014 at 02:28 AM.

  6. #6
    Join Date
    Aug 2008
    Location
    Netherlands
    Posts
    285

    Default

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

  7. #7
    Join Date
    Sep 2013
    Posts
    149

    Default

    Are that much Ubuntu specific articles really necessary? Honestly?

  8. #8
    Join Date
    Oct 2012
    Posts
    248

    Default

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

  9. #9
    Join Date
    Jul 2012
    Posts
    159

    Default

    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?

  10. #10
    Join Date
    Sep 2011
    Posts
    704

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •