1. 21 Sep, 2011 13 commits
  2. 31 Aug, 2011 2 commits
  3. 26 Aug, 2011 1 commit
  4. 15 Aug, 2011 2 commits
    • Adam Jackson's avatar
      fb: Fix memcpy abuse · e32cc0b4
      Adam Jackson authored
      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.)
      
      On an Intel Core i7-2630QM with an NVIDIA GeForce GTX 460M running in
      NoAccel, the broken code and various fixes for -copywinwin{10,100,500}
      gives (edited to fit in 80 columns):
      
      1: Disable the fastpath entirely
      2: Replace memcpy with memmove
      3: This fix
      4: The code before this fix
      
        1            2                 3                 4           Operation
      ------   ---------------   ---------------   ---------------   ------------
      258000   269000 (  1.04)   544000 (  2.11)   552000 (  2.14)   Copy 10x10
       21300    23000 (  1.08)    43700 (  2.05)    47100 (  2.21)   Copy 100x100
         960      962 (  1.00)     1990 (  2.09)     1990 (  2.07)   Copy 500x500
      
      So it's a modest performance hit, but correctness demands it, and it's
      probably worth keeping the 2x speedup from having the fast path in the
      first place.
      Signed-off-by: default avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarKeith Packard <keithp@keithp.com>
      e32cc0b4
    • Pelle Johansson's avatar
      ac2c307f
  5. 10 Aug, 2011 1 commit
  6. 09 Aug, 2011 1 commit
  7. 04 Aug, 2011 3 commits
  8. 31 Jul, 2011 3 commits
  9. 29 Jul, 2011 2 commits
  10. 26 Jul, 2011 10 commits
  11. 20 Jul, 2011 2 commits