I'm assuming this patch is still useful? Bug 36165 is on the 1.11
tracker.
If it's useful, I'll merge it in (with the divide operations replaced
with bit operations; yes, I looked at the assembly output; bpp is
signed, making the operations longer).
It is very useful. This problem is the
@@ -76,8 +77,10 @@ fbBlt (FbBits *srcLine,
}
#endif
- if (alu == GXcopy pm == FB_ALLONES !reverse
- !(srcX 7) !(dstX 7) !(width 7)) {
+ careful = (width 3) (abs(srcLine-dstLine) (FB_SHIFT - 3));
+
+ if (alu == GXcopy pm == FB_ALLONES !careful
+
On Fri, Jun 3, 2011 at 6:34 PM, Soeren Sandmann sandm...@cs.au.dk wrote:
Cyril Brulebois k...@debian.org writes:
Isn't there still a problem here, where srcLine-dstLine is number of
uint32_t's, whereas width * (bpp / 8) is number of bytes?
It looks to me even more extreme than that; both
Cyril Brulebois k...@debian.org (23/05/2011):
except for the micro-opt suggested by Jeremy, no ACK/NACK for that
version?
Sorry to be a pest, but I think it would be worth fixing this crasher
at some point…
Mraw,
KiBi.
signature.asc
Description: Digital signature
Cyril Brulebois k...@debian.org writes:
diff --git a/fb/fbblt.c b/fb/fbblt.c
index 38271c0..b6e7785 100644
--- a/fb/fbblt.c
+++ b/fb/fbblt.c
@@ -65,6 +65,7 @@ fbBlt (FbBits *srcLine,
int n, nmiddle;
BooldestInvarient;
int startbyte, endbyte;
+
except for the micro-opt suggested by Jeremy, no ACK/NACK for that
version?
I'm not subscribed to the list and cannot reply properly therefore, but
I'll try anyway.
I'm running 1.9.5 with this patch applied now, and as far as I can tell,
everything works just fine. I'm the reporter of
Hi,
Cyril Brulebois k...@debian.org (16/05/2011):
From: Adam Jackson a...@redhat.com
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
From: Adam Jackson a...@redhat.com
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
Is the one div needed for:
bpp / 8
bpp % 8
really universally faster than the two bitwise ops needed for
bpp 3
bpp 0x7
? I'm sure most modern compilers will know how to optimize that based on the
target CPU, but I've always tried to avoid doing mults and divs in fast paths
where possible.
On 5/16/11 12:26 PM, Jeremy Huddleston wrote:
Is the one div needed for:
bpp / 8
bpp % 8
really universally faster than the two bitwise ops needed for
bpp 3
bpp 0x7
? I'm sure most modern compilers will know how to optimize that
based on the target CPU, but I've always tried to
10 matches
Mail list logo
