fb: fix fast-path blt detection

The width parameter is used to disable the blit fast-path (memcpy) when
source and destination rows overlap in memory. This check was added in [0].

Unfortunately, the calculation to determine if source and destination
lines overlapped was incorrect:
  (1) it converts width from pixels to bytes, but width is actually in
      bits, not pixels.
  (2) it adds this byte offset to dst/srcLine, which implicitly converts
      the offset from bytes to sizeof(FbBits).

Fix both of these by converting addresses to byte pointers and width
to bytes and doing comparisons on the resulting byte address.

For example:
A 32-bpp 1366 pixel-wide row will have
  width = 1366 * 32 = 43712 bits
  bpp = 32
  (bpp >> 3) = 4
  width * (bpp >> 3) = 174848 FbBits
  (FbBits *)width => 699392 bytes

So, "careful" was true if the destination line was within 699392 bytes,
instead of just within its 1366 * 4 = 5464 byte row.

This bug causes us to take the slow path for large non-overlapping rows
that are "close" in memory.  As a data point, XGetImage(1366x768) on my
ARM chromebook was taking ~140 ms, but with this fixed, it now takes
about 60 ms.
  XGetImage() -> exaGetImage() -> fbGetImage -> fbBlt()

[0] commit e32cc0b4c85c78cd8743a6e1680dcc79054b57ce
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Apr 21 16:37:11 2011 -0400

    fb: Fix memcpy abuse

    The memcpy fast path implicitly assumes that the copy walks
    left-to-right.  That's not something memcpy guarantees, and newer glibc
    on some processors will indeed break that assumption.  Since we walk a
    line at a time, check the source and destination against the width of
    the blit to determine whether we can be sloppy enough to allow memcpy.
    (Having done this, we can remove the check for !reverse as well.)

v3: Convert to byte units

This first checks to make sure the blt is byte aligned, converts all
of the data to byte units and then compares for byte address range
overlap between source and dest.

Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>

0 files changed, 0 insertions, 0 deletions