Announcement

Collapse
No announcement yet.

Intel GPU Driver Tries To Rip Out FBDEV Support

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

  • phoronix
    started a topic Intel GPU Driver Tries To Rip Out FBDEV Support

    Intel GPU Driver Tries To Rip Out FBDEV Support

    Phoronix: Intel GPU Driver Tries To Rip Out FBDEV Support

    Intel's Daniel Vetter is attempting for the Intel DRM graphics driver to remove support for its FBDEV frame-buffer layer with a new patch-set entitled "fbdev no more!", but will this finally usher in the killing of the Linux kernel's FBDEV subsystem?..

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

  • Ericg
    replied
    Originally posted by gilboa View Post
    Just ran oldconfig.

    $ make -j 24
    real 11m1.545s
    user 83m40.261s
    sys 10m17.770s

    $ find | grep .ko$ | wc -l
    2479

    Given the huge number of (default) modules, 30+ on a low end (read: mobile) i5 is acceptable.

    EDIT:
    Noticed my kernel build was still using my secure (encrypted) ccache. Recreated a new ccache home in unencrpyted partition and redid the build on fresh new kernel copy.
    (Also bumped the jobs number... just in-case)

    $ make -j 36
    real 5m4.928s
    user 89m12.660s
    sys 10m51.218s

    - Gilboa

    compiling in RAM, and a localmodconfig cut the compile time down to about 15-20minutes (forgot to add time onto the end, just kept an eye on the clock)

    Thanks for all your helps guys. Much appreciated.

    Leave a comment:


  • gilboa
    replied
    Just ran oldconfig.

    $ make -j 24
    real 11m1.545s
    user 83m40.261s
    sys 10m17.770s

    $ find | grep .ko$ | wc -l
    2479

    Given the huge number of (default) modules, 30+ on a low end (read: mobile) i5 is acceptable.

    EDIT:
    Noticed my kernel build was still using my secure (encrypted) ccache. Recreated a new ccache home in unencrpyted partition and redid the build on fresh new kernel copy.
    (Also bumped the jobs number... just in-case)

    $ make -j 36
    real 5m4.928s
    user 89m12.660s
    sys 10m51.218s

    - Gilboa
    Last edited by gilboa; 06-24-2013, 03:16 PM.

    Leave a comment:


  • Ericg
    replied
    Originally posted by gilboa View Post
    30m with an SSD?!?!?!
    Does your ssd mount options include discard?
    Do you have encryption on your build directory?

    - Gilboa
    Yes; and No.

    Discard isn't necessary for some SSD's, as its handled by the firmware automatically, unfortunately for me... in this one, it is not. Therefore I have to specify it at mount time, or let cron/systemd handle it.

    No encryption on the build directory, but btrfs is set to compress

    And yes its oldconfig -- fedora default config, as such im sure just about every module is set to be compiled lol
    Last edited by Ericg; 06-24-2013, 02:54 PM.

    Leave a comment:


  • gilboa
    replied
    Originally posted by Ericg View Post
    I gotta recompile anyway to test a patch, so I'll see what happens.


    Machine configuration:

    CPU is an Intel i5-2467M clocked at 1.6GHz, dual-core + HT
    Ondemand goveror
    4GB's of RAM
    3.2GB's of SWAP
    HDD's is an SSD, i forget what make and model though.
    Only other speed-bump i could really think of would be to move the sources to /tmp and compile it in /tmp. Since /tmp is tmpfs, shouldn't that run the entire compile straight in RAM instead of hitting the SSD?
    30m with an SSD?!?!?!
    Does your ssd mount options include discard?
    Do you have encryption on your build directory?


    EDIT:
    Come to think about you, are testing oldconfig, right?
    I'm so used to building the kernel with optimized (read: small) configuration, I forgot how huge the default .config is.
    ... So, given the (as far as I remember) size of default configuration, 30m on a fairly low-end machine is more-or-less OK.

    However, the build is very IO intensive, at least on my Xeon workstation (12C/24T, 36GB, 6x300GB in RAID6) the software RAID is the main limiting factor when building the kernel.
    The SSD should have been able to improve this figure by a fairly large margin.

    - Gilboa
    Last edited by gilboa; 06-24-2013, 02:50 PM.

    Leave a comment:


  • Ericg
    replied
    Originally posted by gilboa View Post
    Use top to see what's hogging your CPU.
    Building the kernel, unless you're building 99% of all modules, should be well under 10M. 2-3 on a strong machine.

    BTW, what's your machine hardware configuration (unless I missed it).

    - Gilboa
    I gotta recompile anyway to test a patch, so I'll see what happens.


    Machine configuration:

    CPU is an Intel i5-2467M clocked at 1.6GHz, dual-core + HT
    Ondemand goveror
    4GB's of RAM
    3.2GB's of SWAP
    HDD's is an SSD, i forget what make and model though.
    Only other speed-bump i could really think of would be to move the sources to /tmp and compile it in /tmp. Since /tmp is tmpfs, shouldn't that run the entire compile straight in RAM instead of hitting the SSD?
    Last edited by Ericg; 06-24-2013, 01:07 PM.

    Leave a comment:


  • gilboa
    replied
    Originally posted by Ericg View Post
    make clean, reran oldconfig,bzimage and modules...

    Code:
    ...
    real    29m54.490s
    user    101m40.549s
    sys     8m56.427s
    [[email protected] linux-3.9.5]$
    Odd... I seem to remember this taking longer the first time I did it just a month or so ago...

    Either i timed it with 1 job, there was something else hogging the CPU, (This was run with me still using firefox occasionally, it had the CPU to itself most of the time when I ran it but not all the time), or having yakuake not visible decreases the priority of whatever is running and therefore slows down the compile.
    Use top to see what's hogging your CPU.
    Building the kernel, unless you're building 99% of all modules, should be well under 10M. 2-3 on a strong machine.

    BTW, what's your machine hardware configuration (unless I missed it).

    - Gilboa

    Leave a comment:


  • duby229
    replied
    Compile times really arent that bad on newer hardware. I remember when I first started with gentoo. I was on a 300C Celeron. It was OC'd to 600mhz though. That was the only chip I ever had that I could double the clock. Still took days to compile everything... Now with a 955BE it takes a few hours.

    Leave a comment:


  • Ericg
    replied
    Originally posted by Ibidem View Post
    Considering how much time is spent on modules, try running "make localmodconfig"-it will take the list of loaded modules and enable just those. Of course, you'd better plug in hardware that you'll want to use first, so the modules are loaded. And if you plan to use samba/NTFS/fat, check the filesystems menu (ntfs-3g needs fuse, not kernel ntfs!).
    Once you have a working config, you can keep using it via make oldconfig.

    Also, why the need to patch the Intel driver?

    ...
    By the way, THIS is the big reason that needing extra packages gets annoying. It takes a while to build a kernel, but if you also need to get the latest udev, libdrm, libxkbcommon, etc. that can really get old. And no, I don't intend to stop updating the kernel on my Squeeze system...
    1) I've known about localmodconfig but I've never run it because i know that I'm gonna forget something and I won't realize it until I need it in an emergency.

    2) Patch: https://bugzilla.kernel.org/show_bug.cgi?id=47941#c83 Hardware Quirk that makes the backlight have an acid-trip, because Dell did SUCH a good job of making the XPS 13z Sandy bridge model be "linux certified" -.-

    3) Compiling some things doesn't bother me, I run Arch and Fedora mostly so I'm used to either compiling via the AUR or compiling from git because there werent RPM packages available. But I HATE the thought of reliving my attempted-Gentoo-days where I had to compile every little thing.

    Leave a comment:


  • Ibidem
    replied
    Originally posted by Ericg View Post
    Ideas for how? I've always just put up with it but I'd be open to improvements.
    Considering how much time is spent on modules, try running "make localmodconfig"-it will take the list of loaded modules and enable just those. Of course, you'd better plug in hardware that you'll want to use first, so the modules are loaded. And if you plan to use samba/NTFS/fat, check the filesystems menu (ntfs-3g needs fuse, not kernel ntfs!).
    Once you have a working config, you can keep using it via make oldconfig.

    Also, why the need to patch the Intel driver?

    ...
    By the way, THIS is the big reason that needing extra packages gets annoying. It takes a while to build a kernel, but if you also need to get the latest udev, libdrm, libxkbcommon, etc. that can really get old. And no, I don't intend to stop updating the kernel on my Squeeze system...
    Last edited by Ibidem; 06-20-2013, 07:19 PM.

    Leave a comment:

Working...
X