lkml.org 
[lkml]   [2000]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: vm86 in kernel [was: vesafb...]
    On Tue, 25 Jan 2000, Kendall Bennett wrote:
    > Yes, I am talking about text framebuffer console acceleration and
    > mode sets. Graphics mode consoles can benefit tremendously from
    > hardware accelerated blitting (for scrolling) and hardware
    > accelerated text rendering for drawing the fonts.

    Ok, I'll see what you are getting at considering the statements about
    XFree 4 modularised driver support later.

    Here are some timing results which I consider enlightening. I'll have to
    say I was surpised. These results were gotten by cycling the available
    modes in X and panning around in the virtual screen with a mouse.

    Name|Time (ms)|Times
    -------------------------+---------+-----
    pan_display | 13.587| 268
    encode_fix | 0.011| 21
    set_var | 464.447| 21

    As you can see encode_fix does not call LRMI_int() and the time it takes
    might be mostly gettimeofday() overhead (I have to change my timing
    code to use rdtsc some time). However even pan_display which I know to be
    just a couple of outb-instructions on CT6555x takes 13.5 ms. The time for
    set_var() which might call SET_MODE, SET_LOGICAL_SCAN_LINE_LENGTH and
    SET_DISPLAY_START depending of the mode is almost half a seconds. I have
    to double-check that it does not try to clear the screen by itself but I'm
    sure I got it right. Scheduling policy of the daemon was SCHED_RR.

    > framebuffer console support that can utilise XFree86 4.0 loadable
    > modules to implement the mode set and blitting functions. Why re-
    > write code when it could be re-used (even at the binary level!).

    Which makes sense. I haven't researched this myself but according to Matan
    Ziv-Av (svgalib maintainer) supporting XFree 4 loadable modules will not
    be a easy task. There are apparently hundreds of support functions which
    these drivers need.

    > Forget the VBE 3.0 PMI interface functions, at least for now.
    > Unfortunately a number of well known graphics cards (NVIDIA boards
    > from Diamond) shipped with a broken VBE 3.0 PMI interface. NVIDIA

    I had a feeling that this would be the case. Hence the idea concerning
    black listing BIOSes. Thanks for the information. I knew that the BIOS of
    my laptop (Toshiba) would not be alone in this respect. :(

    > I will email you copies of the code that you can use, under the GPL
    > license. Feel free to cut and paste what stuff you need, but make
    > sure you retain my copyright in your code somewhere.

    Thank you. I certainly will.

    --
    D.


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:56    [W:2.365 / U:0.252 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site