lkml.org 
[lkml]   [2003]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Linux-fbdev-devel] 2.5.66 fbdev performance (was Re: Re: FBdev updates)
    From
    Date
    On Fri, 2003-03-28 at 22:19, Petr Vandrovec wrote:
    >
    > Problem is in the new pixmap handling, especially
    > pixbuf.output - so now instead of memcpy we
    > call some function for copying each byte from
    > font to temporary buffer. As you can see,
    > "constant" portion of time, independent of
    > color depth, increased by 1sec for unaccelerated
    > and by 0.75sec for accelerated putcs.
    > It is 5% to 25% slowdown (5% for 32bpp unaccelerated,
    > 25% for 8bpp accelerated).
    >

    Actually, the slowdown is caused not just by the overhead of the
    read/write methods, but also due to the extra work padding and aligning
    the bitmaps according to requirements of the hardware. This was because
    James wanted support for buffers located not just in system memory but
    also graphics/dma memory.

    The result is that unaccelerated imageblit will slow down while properly
    written accelerated imageblit will experience some speed up (not much,
    probably around 5%).

    We can:

    1. partially reverse the code so it behaves similarly to 2.5.63.
    Support for writing to graphics/dma memory will go away.

    2. split the code path: one will go to the '2.5.63' path, the other
    will go to the '2.5.66' path, depending on the setting of info->pixmap.

    3. keep the code as is

    Personally, I prefer #1, but it's up to James/Geert.

    Tony




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

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