Søren Sandmann [Sun, 8 Dec 2013 14:08:45 +0000 (09:08 -0500)]
Remove all the operators that use division from pixman-combine32.c
These are now handled by floating point combiners.
Søren Sandmann [Sun, 8 Dec 2013 13:51:31 +0000 (08:51 -0500)]
Copy the comments from pixman-combine32.c to pixman-combine-float.c
An upcoming commit will delete many of the operators from
pixman-combine32.c and rely on the ones in pixman-combine-float.c. The
comments about how the operators were derived are still useful though,
so copy them into pixman-combine-float.c before the deletion.
Søren Sandmann Pedersen [Mon, 30 Sep 2013 23:22:20 +0000 (19:22 -0400)]
utils.c: Set DEVIATION to 0.0128
Consider a HARD_LIGHT operation with the following pixels:
- source: 15 (6 bits)
- source alpha: 255 (8 bits)
- mask alpha: 223 (8 bits)
- dest 255 (8 bits)
- dest alpha: 0 (8 bits)
Since 2 times the source is less than source alpha, the first branch
of the hard light blend mode is taken:
(1 - sa) * d + (1 - da) * s + 2 * s * d
Since da is 0 and d is 1, this degenerates to:
(1 - sa) + 3 * s
Taking (src IN mask) into account along with the fact that sa is 1,
this becomes:
(1 - ma) + 3 * s * ma
= (1 - 223/255.0) + 3 * (15/63.0) * (223/255.0)
= 0.
7501400560224089
When computed with the source converted by bit replication to eight
bits, and additionally with the (src IN mask) part rounded to eight
bits, we get:
ma = 223/255.0
s * ma = (60 / 255.0) * (223/255.0) which rounds to 52 / 255
and the result is
(1 - ma) + 3 * s * ma
= (1 - 223/255.0) + 3 * 52/255.0
= 0.
7372549019607844
so now we have an error of 0.012885.
Without making changes to the way pixman does integer
rounding/arithmetic, this error must then be considered
acceptable. Due to conservative computations in the test suite we can
however get away with 0.0128 as the acceptable deviation.
This fixes the remaining failures in pixel-test.
Søren Sandmann [Sun, 24 Nov 2013 00:38:50 +0000 (19:38 -0500)]
Use floating point combiners for all operators that involve divisions
Consider a DISJOINT_ATOP operation with the following pixels:
- source: 0xff (8 bits)
- source alpha: 0x01 (8 bits)
- mask alpha: 0x7b (8 bits)
- dest: 0x00 (8 bits)
- dest alpha: 0xff (8 bits)
When (src IN mask) is computed in 8 bits, the resulting alpha channel
is 0 due to rounding:
floor ((0x01 * 0x7b) / 255.0 + 0.5) = floor (0.9823) = 0
which means that since Render defines any division by zero as
infinity, the Fa and Fb for this operator end up as follows:
Fa = max (1 - (1 - 1) / 0, 0) = 0
Fb = min (1, (1 - 0) / 1) = 1
and so since dest is 0x00, the overall result is 0.
However, when computed in full precision, the alpha value no longer
rounds to 0, and so Fa ends up being
Fa = max (1 - (1 - 1) / 0.0001, 0) = 1
and so the result is now
s * ma * Fa + d * Fb
= (1.0 * (0x7b / 255.0) * 1) + d * 0
= 0x7b / 255.0
= 0.4823
so the error in this case ends up being 0.
48235294, which is clearly
not something that can be considered acceptable.
In order to avoid this problem, we need to do all arithmetic in such a
way that a multiplication of two tiny numbers can never end up being
zero unless one of the input numbers is itself zero.
This patch makes all computations that involve divisions take place in
floating point, which is sufficient to fix the test cases
This brings the number of failures in pixel-test down to 14.
Søren Sandmann [Mon, 18 Nov 2013 18:26:33 +0000 (13:26 -0500)]
Soft Light: Consistent approach to division by zero
The Soft Light operator has several branches. One them is decided
based on whether 2 * s is less than or equal to 2 * sa. In floating
point implementations, when those two values are very close to each
other, it may not be completely predictable which branch we hit.
This is a problem because in one branch, when destination alpha is
zero, we get the result
r = d * as
and in the other we get
r = 0
So when d and as are not 0, this causes two different results to be
returned from essentially identical input values. In other words,
there is a discontinuity in the current implementation.
This patch randomly changes the second branch such that it now returns
d * sa instead. There is no deep meaning behind this, because
essentially this is an attempt to assign meaning to division by zero,
and all that is requires is that that meaning doesn't depend on minute
differences in input values.
This makes the number of failed pixels in pixel-test go down to 347.
Søren Sandmann Pedersen [Fri, 18 Oct 2013 20:39:38 +0000 (16:39 -0400)]
pixman-combine32.c: Fix bugs related to integer promotion
In the component alpha part of the PDF_SEPARABLE_BLEND_MODE macro, the
expression ~RED_8 (m) is used. Because RED_8(m) gets promoted to int
before ~ is applied, the whole expression typically becomes some
negative value rather than (255 - RED_8(m)) as desired.
Fix this by using unsigned temporary variables.
This reduces the number of failures in pixel-test to 363.
Søren Sandmann Pedersen [Sat, 19 Jan 2013 03:25:36 +0000 (22:25 -0500)]
pixman/pixman-combine32.c: Bug fixes for separable blend modes
This commit fixes four separate bugs:
1. In the computation
(1 - sa) * d + (1 - da) * s + sa * da * B(s, d)
we were using regular addition for all four channels, but for
superluminescent pixels, the addition could overflow causing
nonsensical results.
2. The variables and return types used for the results of the blend
mode calculations were unsigned, but for various blend modes (and
especially with superluminescent pixels), the blend mode
calculations could be negative, resulting in underflows.
3. The blend mode computations were returned as 8-bit values, which is
not sufficient precision (especially considering that we need
signed results).
4. The value before the final division by 255 was not properly clamped
to [0, 255].
This patch fixes all those bugs. The blend mode computations are now
returned as signed 16 bit values with 1 represented as 255 * 255.
With these fixes, the number of failing pixels in pixel-test goes down
from 431 to 384.
Søren Sandmann [Wed, 4 Dec 2013 15:06:06 +0000 (10:06 -0500)]
pixel-test.c: Add a number of pixels that have failed at some point
This commit adds a large number of pixel regressions to
pixel-test. All of these have at some point been failing in
blend-mode-test, and most of them do fail currently.
To be specific, with this commit, pixel-test reports 431 failed tests.
Søren Sandmann Pedersen [Thu, 17 Jan 2013 11:36:51 +0000 (06:36 -0500)]
test/tolerance-test: New test program
This new test program is similar to test/composite in that it relies
on the pixel_checker_t API to do tolerance based verification. But
unlike the composite test, which verifies combinations of a fixed set
of pixels, this one generates random images and verifies that those
composite correctly.
Also unlike composite, tolerance-test supports all the separable blend
mode operators in addition to the original Render operators.
When tests fail, a C struct is printed that can be pasted into
pixel-test for regression purposes.
There is an option "--forever" which causes the random seed to be set
to the current time, and then the test runs until interrupted. This is
useful for overnight runs.
This test currently fails badly due to various bugs in the blend mode
operators. Later commits will fix those.
Søren Sandmann [Wed, 4 Dec 2013 15:32:29 +0000 (10:32 -0500)]
pixel-test: Command line argument to specify the regression to run
A new command line argument allows the user to specify which one of
the regressions should be run.
Søren Sandmann [Wed, 4 Dec 2013 15:05:44 +0000 (10:05 -0500)]
pixel-test: Add support for mask pixels
Support is added to pixel-test for verifying operations involving
masks. If a regression includes a mask, it is verified with the
pixel_checker API in in both unified and component alpha modes.
Søren Sandmann Pedersen [Mon, 30 Sep 2013 23:22:11 +0000 (19:22 -0400)]
test/check-formats.c: Add support for separable blend modes
Søren Sandmann Pedersen [Sat, 19 Jan 2013 17:24:07 +0000 (12:24 -0500)]
test/utils.c: Add support for separable blend mode ops to do_composite()
The implementations are copied from the floating point pipeline, but
use double precision instead of single precision.
Søren Sandmann [Thu, 26 Dec 2013 14:41:53 +0000 (09:41 -0500)]
configure.ac: Check and use -Wno-unused-local-typedefs GCC option
With GCC 4.8.2 the COMPILE_TIME_ASSERT macro produces a spurious
warning about an unused local typedef:
In file included from pixman.c:29:0:
pixman.c: In function 'optimize_operator':
pixman-private.h:1019:22: warning: typedef 'compile_time_assertion' locally defined but not used [-Wunused-local-typedefs]
The flag -Wno-unused-local-typedefs suppresses that warning.
Søren Sandmann [Tue, 3 Dec 2013 22:59:42 +0000 (17:59 -0500)]
Soft Light: The first comparison should be <=, not <
According to the definition of soft light, the first comparison is
less-than-or-equal, not less-than.
Søren Sandmann [Sun, 24 Nov 2013 01:30:33 +0000 (20:30 -0500)]
general: Support component alpha for all image types
Currently, if you attempt to use component alpha on source images or
images without RGB channels, Pixman will silently just use unified
alpha instead. This patch makes such images supported for component
alpha.
There is no particularly compelling usecase at the moment, but this
patch does get rid of a bit of special-case code both in
pixman-general.c and in test/composite.c.
Søren Sandmann [Sat, 16 Nov 2013 23:57:01 +0000 (18:57 -0500)]
test/utils.c: Make the stack unaligned only on 32 bit Windows
The call_test_function() contains some assembly that deliberately
causes the stack to be aligned to 32 bits rather than 128 bits on
x86-32. The intention is to catch bugs that surface when pixman is
called from code that only uses a 32 bit alignment.
However, recent versions of GCC apparently make the assumption (either
accidentally or deliberately) that that the incoming stack is aligned
to 128 bits, where older versions only seemed to make this assumption
when compiling with -msse2. This causes the vector code in the PRNG to
now segfault when called from call_test_function() on x86-32.
This patch fixes that by only making the stack unaligned on 32 bit
Windows, where it would definitely be incorrect for GCC to assume that
the incoming stack is aligned to 128 bits.
V2: Put "defined(...)" around __GNUC__
Reviewed-and-Tested-by: Matt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=491110
Jakub Bogusz [Tue, 12 Nov 2013 20:59:42 +0000 (12:59 -0800)]
Fix the SSSE3 CPUID detection.
SSSE3 is detected by bit 9 of ECX, but we were checking bit 9 of EDX
which is APIC leading to SSSE3 routines being called on CPUs without
SSSE3.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Søren Sandmann [Tue, 12 Nov 2013 00:13:31 +0000 (19:13 -0500)]
demos/Makefile.am: Move EXTRA_DIST outside "if HAVE_GTK"
Without this, if tarballs are generated on a system that doesn't have
GTK+ 2 development headers available, the files in EXTRA_DIST will not
be included, which then causes builds from the tarball to fail on
systems that do have GTK+ 2 headers available.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=71465
Andrea Canciani [Mon, 11 Nov 2013 10:21:23 +0000 (11:21 +0100)]
test: Fix the win32 build
The win32 build has no config.h, so HAVE_CONFIG_H should be checked
before including it, as in utils.h.
Søren Sandmann [Sun, 10 Nov 2013 23:17:12 +0000 (18:17 -0500)]
Post-release version bump to 0.33.1
Søren Sandmann [Sun, 10 Nov 2013 23:05:47 +0000 (18:05 -0500)]
Pre-release version bump to 0.32.0
Søren Sandmann Pedersen [Sat, 2 Nov 2013 00:52:00 +0000 (20:52 -0400)]
Post-release version bump to 0.31.3
Søren Sandmann Pedersen [Sat, 2 Nov 2013 00:39:46 +0000 (20:39 -0400)]
Pre-release version bump to 0.31.2
Ritesh Khadgaray [Wed, 23 Oct 2013 21:29:07 +0000 (17:29 -0400)]
pixman_trapezoid_valid(): Fix underflow when bottom is close to MIN_INT
If t->bottom is close to MIN_INT (probably invalid value), subtracting
top can lead to underflow which causes crashes. Attached patch will
fix the issue.
This fixes bug 67484.
Søren Sandmann Pedersen [Wed, 23 Oct 2013 21:28:11 +0000 (17:28 -0400)]
test/trap-crasher.c: Add trapezoid that demonstrates a crash
This trapezoid causes a crash due to an underflow in the
pixman_trapezoid_valid().
Test case from Ritesh Khadgaray.
Brad Smith [Fri, 18 Oct 2013 03:22:02 +0000 (23:22 -0400)]
Fix pixman build with older GCC releases
The following patch fixes building pixman with older GCC releases
such as GCC 3.3 and older (OpenBSD; some older archs use GCC 3.3.6)
by changing the method of detecting the presence of __builtin_clz
to utilizing an autoconf check to determine its presence. Compilers
that pretend to be GCC, implement __builtin_clz and are already
utilizing the intrinsic include LLVM/Clang, Open64, EKOPath and
PCC.
Søren Sandmann Pedersen [Fri, 11 Oct 2013 04:49:44 +0000 (00:49 -0400)]
pixman-glyph.c: Add __force_align_arg_pointer to composite functions
The functions pixman_composite_glyphs_no_mask() and
pixman_composite_glyphs() can call into code compiled with -msse2,
which requires the stack to be aligned to 16 bytes. Since the ABIs on
Windows and Linux for x86-32 don't provide this guarantee, we need to
use this attribute to make GCC generate a prologue that realigns the
stack.
This fixes the crash introduced in the previous commit and also
https://bugs.freedesktop.org/show_bug.cgi?id=70348
and
https://bugs.freedesktop.org/show_bug.cgi?id=68300
Søren Sandmann Pedersen [Wed, 2 Oct 2013 18:38:16 +0000 (14:38 -0400)]
utils.c: On x86-32 unalign the stack before calling test_function
GCC when compiling with -msse2 and -mssse3 will assume that the stack
is aligned to 16 bytes even on x86-32 and accordingly issue movdqa
instructions for stack allocated variables.
But despite what GCC thinks, the standard ABI on x86-32 only requires
a 4-byte aligned stack. This is true at least on Windows, but there
also was (and maybe still is) Linux code in the wild that assumed
this. When such code calls into pixman and hits something compiled
with -msse2, we get a segfault from the unaligned movdqas.
Pixman has worked around this issue in the past with the gcc attribute
"force_align_arg_pointer" but the problem has resurfaced now in
https://bugs.freedesktop.org/show_bug.cgi?id=68300
because pixman_composite_glyphs() is missing this attribute.
This patch makes fuzzer_test_main() call the test_function through a
trampoline, which, on x86-32, has a bit of assembly that deliberately
avoids aligning the stack to 16 bytes as GCC normally expects. The
result is that glyph-test now crashes.
V2: Mark caller-save registers as clobbered, rather than using
noinline on the trampoline.
Siarhei Siamashka [Sat, 5 Oct 2013 19:00:26 +0000 (22:00 +0300)]
configure.ac: check and use -Wdeclaration-after-statement GCC option
The accidental use of declaration after statement breaks compilation
with C89 compilers such as MSVC. Assuming that MSVC is one of the
supported compilers, it makes sense to ask GCC to at least report
warnings for such problematic code.
Siarhei Siamashka [Wed, 2 Oct 2013 00:54:30 +0000 (00:54 +0000)]
sse2: bilinear fast path for src_x888_8888
Running cairo-perf-trace benchmark on Intel Core2 T7300:
Before:
[ 0] image t-firefox-canvas-swscroll 1.989 2.008 0.43% 8/8
[ 1] image firefox-canvas-scroll 4.574 4.609 0.50% 8/8
After:
[ 0] image t-firefox-canvas-swscroll 1.404 1.418 0.51% 8/8
[ 1] image firefox-canvas-scroll 4.228 4.259 0.36% 8/8
Søren Sandmann Pedersen [Thu, 10 Oct 2013 02:12:23 +0000 (22:12 -0400)]
configure.ac: Add check for pmulhuw assembly
Clang 3.0 chokes on the following bit of assembly
asm ("pmulhuw %1, %0\n\t"
: "+y" (__A)
: "y" (__B)
);
from pixman-mmx.c with this error message:
fatal error: error in backend: Unsupported asm: input constraint
with a matching output constraint of incompatible type!
So add a check in configure to only enable MMX when the compiler can
deal with it.
Søren Sandmann Pedersen [Thu, 10 Oct 2013 02:05:59 +0000 (22:05 -0400)]
scale.c: Use int instead of kernel_t for values in named_int_t
The 'value' field in the 'named_int_t' struct is used for both
pixman_repeat_t and pixman_kernel_t values, so the type should be int,
not pixman_kernel_t.
Fixes some warnings like this
scale.c:124:33: warning: implicit conversion from enumeration
type 'pixman_repeat_t' to different enumeration type
'pixman_kernel_t' [-Wconversion]
{ "None", PIXMAN_REPEAT_NONE },
~ ^~~~~~~~~~~~~~~~~~
when compiled with clang.
Søren Sandmann Pedersen [Fri, 4 Oct 2013 20:45:21 +0000 (16:45 -0400)]
pixman-combine32.c: Make Color Burn routine follow the math more closely
For superluminescent destinations, the old code could underflow in
uint32_t r = (ad - d) * as / s;
when (ad - d) was negative. The new code avoids this problem (and
therefore causes changes in the checksums of thread-test and
blitters-test), but it is likely still buggy due to the use of
unsigned variables and other issues in the blend mode code.
Søren Sandmann Pedersen [Fri, 4 Oct 2013 20:40:17 +0000 (16:40 -0400)]
pixman-combine32: Make Color Dodge routine follow the math more closely
Change blend_color_dodge() to follow the math in the comment more
closely.
Note, the new code here is in some sense worse than the old code
because it can now underflow the unsigned variables when the source is
superluminescent and (as - s) is therefore negative. The old code was
careful to clamp to 0.
But for superluminescent variables we really need the ability for the
blend function to become negative, and so the solution the underflow
problem is to just use signed variables. The use of unsigned variables
is a general problem in all of the blend mode code that will have to
be solved later.
The CRC32 values in thread-test and blitters-test are updated to
account for the changes in output.
Søren Sandmann Pedersen [Fri, 4 Oct 2013 20:35:35 +0000 (16:35 -0400)]
pixman-combine32: Rename a number of variable from sa/sca to as/s
There are no semantic changes, just variables renames. The motivation
for these renames is so that the names are shorter and better match
the one used in the comments.
Søren Sandmann Pedersen [Fri, 4 Oct 2013 20:27:39 +0000 (16:27 -0400)]
pixman-combine32: Improve documentation for blend mode operators
This commit overhauls the comments in pixman-comine32.c regarding
blend modes:
- Add a link to the PDF supplement that clarifies the specification of
ColorBurn and ColorDodge
- Clarify how the formulas for premultiplied colors are derived form
the ones in the PDF specifications
- Write out the derivation of the formulas in each blend routine
Søren Sandmann Pedersen [Fri, 4 Oct 2013 20:40:23 +0000 (16:40 -0400)]
pixman-combine32.c: Formatting fixes
Fix a bunch of spacing issues.
V2: More spacing issues, in the _ca combiners
Andrea Canciani [Wed, 9 Oct 2013 16:23:27 +0000 (18:23 +0200)]
Fix thread-test on non-OpenMP systems
The non-reentrant versions of prng_* functions are thread-safe only in
OpenMP-enabled builds.
Fixes thread-test failing when compiled with Clang (both on Linux and
on MacOS).
Andrea Canciani [Thu, 26 Sep 2013 07:23:41 +0000 (09:23 +0200)]
Add support for SSSE3 to the MSVC build system
Handle SSSE3 just like MMX and SSE2.
Andrea Canciani [Thu, 26 Sep 2013 07:26:17 +0000 (09:26 +0200)]
Fix build of check-formats on MSVC
Fixes
check-formats.obj : error LNK2019: unresolved external symbol
_strcasecmp referenced in function _format_from_string
check-formats.obj : error LNK2019: unresolved external symbol
_snprintf referenced in function _list_operators
Andrea Canciani [Thu, 26 Sep 2013 07:12:31 +0000 (09:12 +0200)]
Fix building of "other" programs on MSVC
In
d1434d112ca5cd325e4fb85fc60afd1b9e902786 the benchmarks have been
extended to include other programs as well and the variable names have
been updated accordingly in the autotools-based build system, but not
in the MSVC one.
Andrea Canciani [Thu, 26 Sep 2013 07:16:41 +0000 (09:16 +0200)]
Fix build on MSVC
After
a4c79d695d52c94647b1aff78548e5892d616b70 the MMX and SSE2 code
has some declarations after the beginning of a block, which is not
allowed by MSVC.
Fixes multiple errors like:
pixman-mmx.c(3625) : error C2275: '__m64' : illegal use of this type
as an expression
pixman-sse2.c(5708) : error C2275: '__m128i' : illegal use of this
type as an expression
Søren Sandmann Pedersen [Wed, 2 Oct 2013 21:51:36 +0000 (17:51 -0400)]
fast: Swap image and iter flags in generated fast paths
The generated fast paths that were moved into the 'fast'
implementation in
ec0e38cbb746a673f8e989ab8eae356c8c77dac7 had their
image and iter flag arguments swapped; as a result, none of the fast
paths were ever called.
Siarhei Siamashka [Sat, 28 Sep 2013 01:51:21 +0000 (04:51 +0300)]
vmx: there is no need to handle unaligned destination anymore
So the redundant variables, memory reads/writes and reshuffles
can be safely removed. For example, this makes the inner loop
of 'vmx_combine_add_u_no_mask' function much more simple.
Before:
7a20:7d a8 48 ce lvx v13,r8,r9
7a24:7d 80 48 ce lvx v12,r0,r9
7a28:7d 28 50 ce lvx v9,r8,r10
7a2c:7c 20 50 ce lvx v1,r0,r10
7a30:39 4a 00 10 addi r10,r10,16
7a34:10 0d 62 eb vperm v0,v13,v12,v11
7a38:10 21 4a 2b vperm v1,v1,v9,v8
7a3c:11 2c 6a eb vperm v9,v12,v13,v11
7a40:10 21 4a 00 vaddubs v1,v1,v9
7a44:11 a1 02 ab vperm v13,v1,v0,v10
7a48:10 00 0a ab vperm v0,v0,v1,v10
7a4c:7d a8 49 ce stvx v13,r8,r9
7a50:7c 00 49 ce stvx v0,r0,r9
7a54:39 29 00 10 addi r9,r9,16
7a58:42 00 ff c8 bdnz+ 7a20 <.vmx_combine_add_u_no_mask+0x120>
After:
76c0:7c 00 48 ce lvx v0,r0,r9
76c4:7d a8 48 ce lvx v13,r8,r9
76c8:39 29 00 10 addi r9,r9,16
76cc:7c 20 50 ce lvx v1,r0,r10
76d0:10 00 6b 2b vperm v0,v0,v13,v12
76d4:10 00 0a 00 vaddubs v0,v0,v1
76d8:7c 00 51 ce stvx v0,r0,r10
76dc:39 4a 00 10 addi r10,r10,16
76e0:42 00 ff e0 bdnz+ 76c0 <.vmx_combine_add_u_no_mask+0x120>
Siarhei Siamashka [Sat, 28 Sep 2013 00:48:07 +0000 (03:48 +0300)]
vmx: align destination to fix valgrind invalid memory writes
The SIMD optimized inner loops in the VMX/Altivec code are trying
to emulate unaligned accesses to the destination buffer. For each
4 pixels (which fit into a 128-bit register) the current
implementation:
1. first performs two aligned reads, which cover the needed data
2. reshuffles bytes to get the needed data in a single vector register
3. does all the necessary calculations
4. reshuffles bytes back to their original location in two registers
5. performs two aligned writes back to the destination buffer
Unfortunately in the case if the destination buffer is unaligned and
the width is a perfect multiple of 4 pixels, we may have some writes
crossing the boundaries of the destination buffer. In a multithreaded
environment this may potentially corrupt the data outside of the
destination buffer if it is concurrently read and written by some
other thread.
The valgrind report for blitters-test is full of:
==23085== Invalid write of size 8
==23085== at 0x1004B0B4: vmx_combine_add_u (pixman-vmx.c:1089)
==23085== by 0x100446EF: general_composite_rect (pixman-general.c:214)
==23085== by 0x10002537: test_composite (blitters-test.c:363)
==23085== by 0x1000369B: fuzzer_test_main._omp_fn.0 (utils.c:733)
==23085== by 0x10004943: fuzzer_test_main (utils.c:728)
==23085== by 0x10002C17: main (blitters-test.c:397)
==23085== Address 0x5188218 is 0 bytes after a block of size 88 alloc'd
==23085== at 0x4051DA0: memalign (vg_replace_malloc.c:581)
==23085== by 0x4051E7B: posix_memalign (vg_replace_malloc.c:709)
==23085== by 0x10004CFF: aligned_malloc (utils.c:833)
==23085== by 0x10001DCB: create_random_image (blitters-test.c:47)
==23085== by 0x10002263: test_composite (blitters-test.c:283)
==23085== by 0x1000369B: fuzzer_test_main._omp_fn.0 (utils.c:733)
==23085== by 0x10004943: fuzzer_test_main (utils.c:728)
==23085== by 0x10002C17: main (blitters-test.c:397)
This patch addresses the problem by first aligning the destination
buffer at a 16 byte boundary in each combiner function. This trick
is borrowed from the pixman SSE2 code.
It allows to pass the new thread-test on PowerPC VMX/Altivec systems and
also resolves the "make check" failure reported for POWER7 hardware:
http://lists.freedesktop.org/archives/pixman/2013-August/002871.html
Søren Sandmann Pedersen [Sat, 28 Sep 2013 05:10:24 +0000 (01:10 -0400)]
test: Add new thread-test program
This test program allocates an array of 16 * 7 uint32_ts and spawns 16
threads that each use 7 of the allocated uint32_ts as a destination
image for a large number of composite operations. Each thread then
computes and returns a checksum for the image. Finally, the main
thread computes a checksum of the checksums and verifies that it
matches expectations.
The purpose of this test is catch errors where memory outside images
is read and then written back. Such out-of-bounds accesses are broken
when multiple threads are involved, because the threads will race to
read and write the shared memory.
V2:
- Incorporate fixes from Siarhei for endianness and undefined behavior
regarding argument evaluation
- Make the images 7 pixels wide since the bug only happens when the
composite width is greater than 4.
- Compute a checksum of the checksums so that you don't have to
update 16 values if something changes.
V3: Remove stray dollar sign
Søren Sandmann Pedersen [Sat, 28 Sep 2013 05:03:55 +0000 (01:03 -0400)]
Rename HAVE_PTHREAD_SETSPECIFIC to HAVE_PTHREADS
The test for pthread_setspecific() can be used as a general test for
whether pthreads are available, so rename the variable from
HAVE_PTHREAD_SETSPECIFIC to HAVE_PTHREADS and run the test even when
better support for thread local variables are available.
However, the pthread arguments are still only added to CFLAGS and
LDFLAGS when pthread_setspecific() is used for thread local variables.
V2: AC_SUBST(PTHREAD_CFLAGS)
Søren Sandmann Pedersen [Sun, 29 Sep 2013 20:47:53 +0000 (16:47 -0400)]
blitters-test: Remove unused variable
Søren Sandmann Pedersen [Thu, 26 Sep 2013 22:56:07 +0000 (18:56 -0400)]
utils.c: Make image_endian_swap() deal with negative strides
Use a temporary variable s containing the absolute value of the stride
as the upper bound in the inner loops.
V2: Do this for the bpp == 16 case as well
Søren Sandmann Pedersen [Fri, 20 Sep 2013 06:45:32 +0000 (02:45 -0400)]
utils.c: Make print_image actually cope with negative strides
Commit
4312f077365bf9f59423b1694136089c6da6216b claimed to have made
print_image() work with negative strides, but it didn't actually
work. When the stride was negative, the image buffer would be accessed
as if the stride were positive.
Fix the bug by not changing the stride variable and instead using a
temporary, s, that contains the absolute value of stride.
Søren Sandmann Pedersen [Sat, 31 Aug 2013 20:54:51 +0000 (16:54 -0400)]
Move generated affine fetchers into pixman-fast-path.c
The generated fetchers for NEAREST, BILINEAR, and
SEPARABLE_CONVOLUTION filters are fast paths and so they belong in
pixman-fast-path.c
Søren Sandmann Pedersen [Sat, 31 Aug 2013 20:40:43 +0000 (16:40 -0400)]
Move bits_image_fetch_bilinear_no_repeat_8888 into pixman-fast-path.c
This iterator is really a fast path, so it belongs in the fast path
implementation.
Søren Sandmann Pedersen [Wed, 11 Sep 2013 04:24:23 +0000 (00:24 -0400)]
fast, ssse3: Simplify logic to fetch lines in the bilinear iterators
Instead of having logic to swap the lines around when one of them
doesn't match, store the two lines in an array and use the least
significant bit of the y coordinate as the index into that
array. Since the two lines always have different least significant
bits, they will never collide.
The effect is that lines corresponding to even y coordinates are
stored in info->lines[0] and lines corresponding to odd y coordinates
are stored in info->lines[1].
Søren Sandmann Pedersen [Thu, 12 Sep 2013 02:17:33 +0000 (22:17 -0400)]
test: Test negative strides
Pixman supports negative strides, but up until now they haven't been
tested outside of stress-test. This commit adds testing of negative
strides to blitters-test, scaling-test, affine-test, rotate-test, and
composite-traps-test.
Søren Sandmann Pedersen [Thu, 12 Sep 2013 16:52:02 +0000 (12:52 -0400)]
test: Share the image printing code
The affine-test, blitters-test, and scaling-test all have the ability
to print out the bytes of the destination image. Share this code by
moving it to utils.c.
At the same time make the code work correctly with negative strides.
Søren Sandmann Pedersen [Thu, 12 Sep 2013 16:24:52 +0000 (12:24 -0400)]
{scaling,affine,composite-traps}-test: Use compute_crc32_for_image()
By using this function instead of compute_crc32() the alpha masking
code and the call to image_endian_swap() are not duplicated.
Søren Sandmann Pedersen [Tue, 10 Sep 2013 13:44:40 +0000 (09:44 -0400)]
pixman-filter.c: Use 65536, not 65535, for fixed point conversion
Converting a double precision number to 16.16 fixed point should be
done by multiplying with 65536.0, not 65535.0.
The bug could potentially cause certain filters that would otherwise
leave the image bit-for-bit unchanged under an identity
transformation, to not do so, but the numbers are close enough that
there weren't any visual differences.
Søren Sandmann Pedersen [Tue, 10 Sep 2013 13:37:38 +0000 (09:37 -0400)]
demos/scale.ui: Allow subsample_bits to be 0
The separable convolution filter supports a subsample_bits of 0 which
corresponds to no subsampling at all, so allow this value to be used
in the scale demo.
Søren Sandmann Pedersen [Thu, 6 Jun 2013 20:15:39 +0000 (16:15 -0400)]
ssse3: Add iterator for separable bilinear scaling
This new iterator uses the SSSE3 instructions pmaddubsw and pabsw to
implement a fast iterator for bilinear scaling.
There is a graph here recording the per-pixel time for various
bilinear scaling algorithms as reported by scaling-bench:
http://people.freedesktop.org/~sandmann/ssse3.v2/ssse3.v2.png
As the graph shows, this new iterator is clearly faster than the
existing C iterator, and when used with an SSE2 combiner, it is also
faster than the existing SSE2 fast paths for upscaling, though not for
downscaling.
Another graph:
http://people.freedesktop.org/~sandmann/ssse3.v2/movdqu.png
shows the difference between writing to iter->buffer with movdqa,
movdqu on an aligned buffer, and movdqu on a deliberately unaligned
buffer. Since the differences are very small, the patch here avoids
using movdqa because imposing alignment restrictions on iter->buffer
may interfere with other optimizations, such as writing directly to
the destination image.
The data was measured with scaling-bench on a Sandy Bridge Core
i3-2350M @ 2.3GHz and is available in this directory:
http://people.freedesktop.org/~sandmann/ssse3.v2/
where there is also a Gnumeric spreadsheet ssse3.v2.gnumeric
containing the per-pixel values and the graph.
V2:
- Use uintptr_t instead of unsigned long in the ALIGN macro
- Use _mm_storel_epi64 instead of _mm_cvtsi128_si64 as the latter form
is not available on x86-32.
- Use _mm_storeu_si128() instead of _mm_store_si128() to avoid
imposing alignment requirements on iter->buffer
Søren Sandmann Pedersen [Thu, 6 Jun 2013 20:32:59 +0000 (16:32 -0400)]
Add empty SSSE3 implementation
This commit adds a new, empty SSSE3 implementation and the associated
build system support.
configure.ac: detect whether the compiler understands SSSE3
intrinsics and set up the required CFLAGS
Makefile.am: Add libpixman-ssse3.la
pixman-x86.c: Add X86_SSSE3 feature flag and detect it in
detect_cpu_features().
pixman-ssse3.c: New file with an empty SSSE3 implementation
V2: Remove SSSE3_LDFLAGS since it isn't necessary unless Solaris
support is added.
Søren Sandmann Pedersen [Wed, 28 Aug 2013 19:36:13 +0000 (15:36 -0400)]
general: Ensure that iter buffers are aligned to 16 bytes
At the moment iter buffers are only guaranteed to be aligned to a 4
byte boundary. SIMD implementations benefit from the buffers being
aligned to 16 bytes, so ensure this is the case.
V2:
- Use uintptr_t instead of unsigned long
- allocate 3 * SCANLINE_BUFFER_LENGTH byte on stack rather than just
SCANLINE_BUFFER_LENGTH
- use sizeof (stack_scanline_buffer) instead of SCANLINE_BUFFER_LENGTH
to determine overflow
Siarhei Siamashka [Tue, 3 Sep 2013 01:39:54 +0000 (04:39 +0300)]
sse2: faster bilinear scaling (pack 4 pixels to write with MOVDQA)
The loops are already unrolled, so it was just a matter of packing
4 pixels into a single XMM register and doing aligned 128-bit
writes to memory via MOVDQA instructions for the SRC compositing
operator fast path. For the other fast paths, this XMM register
is also directly routed to further processing instead of doing
extra reshuffling. This replaces "8 PACKSSDW/PACKUSWB + 4 MOVD"
instructions with "3 PACKSSDW/PACKUSWB + 1 MOVDQA" per 4 pixels,
which results in a clear performance improvement.
There are also some other (less important) tweaks:
1. Convert 'pixman_fixed_t' to 'intptr_t' before using it as an
index for addressing memory. The problem is that 'pixman_fixed_t'
is a 32-bit data type and it has to be extended to 64-bit
offsets, which needs extra instructions on 64-bit systems.
2. Allow to recalculate the horizontal interpolation weights only
once per 4 pixels by treating the XMM register as four pairs
of 16-bit values. Each of these 16-bit/16-bit pairs can be
replicated to fill the whole 128-bit register by using PSHUFD
instructions. So we get "3 PADDW/PSRLW + 4 PSHUFD" instructions
per 4 pixels instead of "12 PADDW/PSRLW" per 4 pixels
(or "3 PADDW/PSRLW" per each pixel).
Now a good question is whether replacing "9 PADDW/PSRLW" with
"4 PSHUFD" is a favourable exchange. As it turns out, PSHUFD
instructions are very fast on new Intel processors (including
Atoms), but are rather slow on the first generation of Core2
(Merom) and on the other processors from that time or older.
A good instructions latency/throughput table, covering all the
relevant processors, can be found at:
http://www.agner.org/optimize/instruction_tables.pdf
Enabling this optimization is controlled by the PSHUFD_IS_FAST
define in "pixman-sse2.c".
3. One use of PSHUFD instruction (_mm_shuffle_epi32 intrinsic) in
the older code has been also replaced by PUNPCKLQDQ equivalent
(_mm_unpacklo_epi64 intrinsic) in PSHUFD_IS_FAST=0 configuration.
The PUNPCKLQDQ instruction is usually faster on older processors,
but has some side effects (instead of fully overwriting the
destination register like PSHUFD does, it retains half of the
original value, which may inhibit some compiler optimizations).
Benchmarks with "lowlevel-blt-bench -b src_8888_8888" using GCC 4.8.1 on
x86-64 system and default optimizations. The results are in MPix/s:
====== Intel Core2 T7300 (2GHz) ======
old: src_8888_8888 = L1: 128.69 L2: 125.07 M:124.86
over_8888_8888 = L1: 83.19 L2: 81.73 M: 80.63
over_8888_n_8888 = L1: 79.56 L2: 78.61 M: 77.85
over_8888_8_8888 = L1: 77.15 L2: 75.79 M: 74.63
new (PSHUFD_IS_FAST=0): src_8888_8888 = L1: 168.67 L2: 163.26 M:162.44
over_8888_8888 = L1: 102.91 L2: 100.43 M: 99.01
over_8888_n_8888 = L1: 97.40 L2: 95.64 M: 94.24
over_8888_8_8888 = L1: 98.04 L2: 95.83 M: 94.33
new (PSHUFD_IS_FAST=1): src_8888_8888 = L1: 154.67 L2: 149.16 M:148.48
over_8888_8888 = L1: 95.97 L2: 93.90 M: 91.85
over_8888_n_8888 = L1: 93.18 L2: 91.47 M: 90.15
over_8888_8_8888 = L1: 95.33 L2: 93.32 M: 91.42
====== Intel Core i7 860 (2.8GHz) ======
old: src_8888_8888 = L1: 323.48 L2: 318.86 M:314.81
over_8888_8888 = L1: 187.38 L2: 186.74 M:182.46
new (PSHUFD_IS_FAST=0): src_8888_8888 = L1: 373.06 L2: 370.94 M:368.32
over_8888_8888 = L1: 217.28 L2: 215.57 M:211.32
new (PSHUFD_IS_FAST=1): src_8888_8888 = L1: 401.98 L2: 397.65 M:395.61
over_8888_8888 = L1: 218.89 L2: 217.56 M:213.48
The most interesting benchmark is "src_8888_8888" (because this code can
be reused for a generic non-separable SSE2 bilinear fetch iterator).
The results shows that PSHUFD instructions are bad for Intel Core2 T7300
(Merom core) and good for Intel Core i7 860 (Nehalem core). Both of these
processors support SSSE3 instructions though, so they are not the primary
targets for SSE2 code. But without having any other more relevant hardware
to test, PSHUFD_IS_FAST=0 seems to be a reasonable default for SSE2 code
and old processors (until the runtime CPU features detection becomes
clever enough to recognize different microarchitectures).
(Rebased on top of patch that removes support for 8-bit bilinear
filtering -ssp)
Siarhei Siamashka [Thu, 5 Sep 2013 05:07:52 +0000 (08:07 +0300)]
test: safeguard the scaling-bench test against COW
The calloc call from pixman_image_create_bits may still
rely on http://en.wikipedia.org/wiki/Copy-on-write
Explicitly initializing the destination image results in
a more predictable behaviour.
V2:
- allocate 16 bytes aligned buffer with aligned stride instead
of delegating this to pixman_image_create_bits
- use memset for the allocated buffer instead of pixman solid fill
- repeat tests 3 times and select best results in order to filter
out even more measurement noise
Søren Sandmann Pedersen [Thu, 5 Sep 2013 02:32:15 +0000 (22:32 -0400)]
Drop support for 8-bit precision in bilinear filtering
The default has been 7-bit for a while now, and the quality
improvement with 8-bit precision is not enough to justify keeping the
code around as a compile-time option.
Søren Sandmann Pedersen [Sun, 1 Sep 2013 02:59:53 +0000 (22:59 -0400)]
Make the first argument to scanline fetchers have type bits_image_t *
Scanline fetchers haven't been used for images other than bits for a
long time, so by making the type reflect this fact, a bit of casting
can be saved in various places.
Matt Turner [Tue, 30 Jul 2013 20:22:29 +0000 (13:22 -0700)]
iwmmxt: Disallow if gcc version is < 4.8.
Later versions of gcc-4.7.x are capable of generating iwMMXt
instructions properly, but gcc-4.8 contains better support and other
fixes, including iwMMXt in conjunction with hardfp. The existing 4.5
requirement was based on attempts to have OLPC use a patched gcc to
build pixman. Let's just require gcc-4.8.
Søren Sandmann Pedersen [Wed, 28 Aug 2013 04:38:22 +0000 (00:38 -0400)]
fast_bilinear_cover_init: Don't install a finalizer on the error path
No memory is allocated in the error case, so a finalizer is not
necessary, and will cause problems if the data pointer is not
initialized to NULL.
Søren Sandmann Pedersen [Thu, 24 May 2012 06:49:05 +0000 (02:49 -0400)]
Add an iterator that can fetch bilinearly scaled images
This new iterator works in a separable way; that is, for a destination
scaline, it scales the two involved source scanlines and then caches
them so that they can be reused for the next destination scanlines.
There are two versions of the code, one that uses 64 bit arithmetic,
and one that uses 32 bit arithmetic only. The latter version is
used on 32 bit systems, where it is expected to be faster.
This scheme saves a substantial amount of arithmetic for larger
scalings; the per-pixel times for various configurations as reported
by scaling-bench are graphed here:
http://people.freedesktop.org/~sandmann/separable.v2/v2.png
The "sse2" graph is current default on x86, "mmx" is with sse2
disabled, "old c" is with sse2 and mmx disabled. The "new 32" and "new
64" graphs show times for the new code. As the graphs show, the 64 bit
version of the new code beats the "old c" for all scaling ratios.
The data was taken on a Sandy Bridge Core i3-2350M CPU @ 2.0 GHz
running in 64 bit mode.
The data used to generate the graph is available in this directory:
http://people.freedesktop.org/~sandmann/separable.v2/
There is also a Gnumeric spreadsheet v2.gnumeric containing the
per-pixel values and the graph.
V2:
- Add error message in the OOM/bad matrix case
- Save some shifts by storing the cached scanlines in AGBR order
- Special cased version that uses 32 bit arithmetic when sizeof(long) <= 4
Søren Sandmann Pedersen [Fri, 25 May 2012 15:38:41 +0000 (11:38 -0400)]
Add support for iter finalizers
Iterators may sometimes need to allocate auxillary memory. In order to
be able to free this memory, optional iterator finalizers are
required.
Søren Sandmann Pedersen [Wed, 22 May 2013 22:48:08 +0000 (18:48 -0400)]
test/scaling-bench.c: New benchmark for bilinear scaling
This new benchmark scales a 320 x 240 test a8r8g8b8 image by all
ratios from 0.1, 0.2, ... up to 10.0 and reports the time it to took
to do each of the scaling operations, and the time spent per
destination pixel.
The times reported for the scaling operations are given in
milliseconds, the times-per-pixel are in nanoseconds.
V2: Format output better
Søren Sandmann Pedersen [Wed, 7 Aug 2013 14:21:20 +0000 (10:21 -0400)]
RELEASING: Add note about changing the topic of the #cairo IRC channel
Siarhei Siamashka [Sat, 27 Jul 2013 16:25:32 +0000 (19:25 +0300)]
test: fix matrix-test on big endian systems
Andrea Canciani [Tue, 17 Jul 2012 14:14:20 +0000 (16:14 +0200)]
test: Fix build on MSVC
The MSVC compiler is very strict about variable declarations after
statements.
Move all the declarations of each block before any statement in the
same block to fix multiple instances of:
alpha-loop.c(XX) : error C2275: 'pixman_image_t' : illegal use of this
type as an expression
Alexander Troosh [Tue, 11 Jun 2013 11:55:34 +0000 (15:55 +0400)]
Require GTK+ version >= 2.16
I'm got bug in my system:
lcc: "scale.c", line 374: warning: function "gtk_scale_add_mark" declared
implicitly [-Wimplicit-function-declaration]
gtk_scale_add_mark (GTK_SCALE (widget), 0.0, GTK_POS_LEFT, NULL);
^
CCLD scale
scale.o: In function `app_new':
(.text+0x23e4): undefined reference to `gtk_scale_add_mark'
scale.o: In function `app_new':
(.text+0x250c): undefined reference to `gtk_scale_add_mark'
scale.o: In function `app_new':
(.text+0x2634): undefined reference to `gtk_scale_add_mark'
make[2]: *** [scale] Error 1
make[2]: Target `all' not remade because of errors.
$ pkg-config --modversion gtk+-2.0
2.12.1
The demos/scale.c use call to gtk_scale_add_mark() function from 2.16+
version of GTK+. Need do support old GTK+ (rewrite scale.c) or simple
demand of high version of GTK+, like this:
Matthieu Herrb [Sat, 8 Jun 2013 16:07:20 +0000 (18:07 +0200)]
configure.ac: Don't use '+=' since it's not POSIX
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Søren Sandmann Pedersen [Wed, 22 May 2013 13:01:36 +0000 (09:01 -0400)]
Consolidate all the iter_init_bits_stride functions
The SSE2, MMX, and fast implementations all have a copy of the
function iter_init_bits_stride that computes an image buffer and
stride.
Move that function to pixman-utils.c and share it among all the
implementations.
Søren Sandmann Pedersen [Tue, 21 May 2013 10:40:59 +0000 (06:40 -0400)]
Delete the old src/dest_iter_init() functions
Now that we are using the new _pixman_implementation_iter_init(), the
old _src/_dest_iter_init() functions are no longer needed, so they can
be deleted, and the corresponding fields in pixman_implementation_t
can be removed.
Søren Sandmann Pedersen [Tue, 21 May 2013 12:15:41 +0000 (08:15 -0400)]
Add _pixman_implementation_iter_init() and use instead of _src/_dest_init()
A new field, 'iter_info', is added to the implementation struct, and
all the implementations store a pointer to their iterator tables in
it. A new function, _pixman_implementation_iter_init(), is then added
that searches those tables, and the new function is called in
pixman-general.c and pixman-image.c instead of the old
_pixman_implementation_src_init() and _pixman_implementation_dest_init().
Søren Sandmann Pedersen [Wed, 22 May 2013 12:05:55 +0000 (08:05 -0400)]
general: Store the iter initializer in a one-entry pixman_iter_info_t table
In preparation for sharing all iterator initialization code from all
the implementations, move the general implementation to use a table of
pixman_iter_info_t.
The existing src_iter_init and dest_iter_init functions are
consolidated into one general_iter_init() function that checks the
iter_flags for whether it is dealing with a source or destination
iterator.
Unlike in the other implementations, the general_iter_init() function
stores its own get_scanline() and write_back() functions in the
iterator, so it relies on the initializer being called after
get_scanline and write_back being copied from the struct to the
iterator.
Søren Sandmann Pedersen [Tue, 21 May 2013 07:59:06 +0000 (03:59 -0400)]
fast: Replace the fetcher_info_t table with a pixman_iter_info_t table
Similar to the SSE2 and MMX patches, this commit replaces a table of
fetcher_info_t with a table of pixman_iter_info_t, and similar to the
noop patch, both fast_src_iter_init() and fast_dest_iter_init() are
now doing exactly the same thing, so their code can be shared in a new
function called fast_iter_init_common().
Søren Sandmann Pedersen [Tue, 21 May 2013 07:32:32 +0000 (03:32 -0400)]
mmx: Replace the fetcher_info_t table with a pixman_iter_info_t table
Similar to the SSE2 commit, information about the iterators is stored
in a table of pixman_iter_info_t.
Søren Sandmann Pedersen [Tue, 21 May 2013 07:29:09 +0000 (03:29 -0400)]
sse2: Replace the fetcher_info_t table with a pixman_iter_info_t table
Similar to the changes to noop, put all the iterators into a table of
pixman_iter_info_t and then do a generic search of that table during
iterator initialization.
Søren Sandmann Pedersen [Tue, 21 May 2013 12:14:44 +0000 (08:14 -0400)]
noop: Keep information about iterators in an array of pixman_iter_info_t
Instead of having a nest of if statements, store the information about
iterators in a table of a new struct type, pixman_iter_info_t, and
then walk that table when initializing iterators.
The new struct contains a format, a set of image flags, and a set of
iter flags, plus a pixman_iter_get_scanline_t, a
pixman_iter_write_back_t, and a new function type
pixman_iter_initializer_t.
If the iterator matches an entry, it is first initialized with the
given get_scanline and write_back functions, and then the provided
iter_initializer (if present) is run. Running the iter_initializer
after setting get_scanline and write_back allows the initializer to
override those fields if it wishes.
The table contains both source and destination iterators,
distinguished based on the recently-added ITER_SRC and ITER_DEST;
similarly, wide iterators are recognized with the ITER_WIDE
flag. Having both source and destination iterators in the table means
the noop_src_iter_init() and noop_dest_iter_init() functions become
identical, so this patch factors out their code in a new function
noop_iter_init_common() that both calls.
The following patches in this series will change all the
implementations to use an iterator table, and then move the table
search code to pixman-implementation.c.
Søren Sandmann Pedersen [Mon, 20 May 2013 13:44:05 +0000 (09:44 -0400)]
Always set the FAST_PATH_NO_ALPHA_MAP flag for non-BITS images
We only support alpha maps for BITS images, so it's always to ignore
the alpha map for non-BITS image. This makes it possible get rid of
the check for SOLID images since it will now be subsumed by the check
for FAST_PATH_NO_ALPHA_MAP.
Opaque masks are reduced to NULL images in pixman.c, and those can
also safely be treated as not having an alpha map, so set the
FAST_PATH_NO_ALPHA_MAP bit for those as well.
Søren Sandmann Pedersen [Thu, 6 Dec 2012 07:25:35 +0000 (02:25 -0500)]
Add ITER_WIDE iter flag
This will be useful for putting iterators into tables where they can
be looked up by iterator flags. Without this flag, wide iterators can
only be recognized by the absence of ITER_NARROW, which makes testing
for a match difficult.
Søren Sandmann Pedersen [Mon, 20 May 2013 13:04:22 +0000 (09:04 -0400)]
Add ITER_SRC and ITER_DEST iter flags
These indicate whether the iterator is for a source or a destination
image. Note iterator initializers are allowed to rely on one of these
being set, so they can't be left out the way it's generally harmless
(aside from potentil performance degradation) to leave out a
particular fast path flag.
Søren Sandmann Pedersen [Sat, 18 May 2013 15:39:34 +0000 (11:39 -0400)]
Make use of image flag in noop iterators
Similar to
c2230fe2aff, simply check against SAMPLES_COVER_CLIP_NEAREST
instead of comparing all the x/y/width/height parameters.
Markos Chandras [Wed, 15 May 2013 16:51:20 +0000 (09:51 -0700)]
Use AC_LINK_IFELSE to check if the Loongson MMI code can link
The Loongson code is compiled with -march=loongson2f to enable the MMI
instructions, but binutils refuses to link object code compiled with
different -march settings, leading to link failures later in the
compile. This avoids that problem by checking if we can link code
compiled for Loongson.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Matt Turner [Tue, 14 May 2013 19:40:50 +0000 (12:40 -0700)]
mmx: Document implementation(s) of pix_multiply().
I look at that function and can never remember what it does or how it
manages to do it.
ingmar@irsoft.de [Sat, 11 May 2013 09:55:04 +0000 (11:55 +0200)]
Fix broken build when HAVE_CONFIG_H is undefined, e.g. on Win32.
Build fix for platforms without a generated config.h, for example Win32.
Søren Sandmann Pedersen [Wed, 8 May 2013 23:40:12 +0000 (19:40 -0400)]
Post-release version bump to 0.31.1
Søren Sandmann Pedersen [Wed, 8 May 2013 23:31:22 +0000 (19:31 -0400)]
Pre-release version bump to 0.30.0
Søren Sandmann Pedersen [Tue, 30 Apr 2013 22:57:43 +0000 (18:57 -0400)]
Post-release version bump to 0.29.5
Søren Sandmann Pedersen [Tue, 30 Apr 2013 22:50:04 +0000 (18:50 -0400)]
Pre-release version bump to 0.29.4
Søren Sandmann Pedersen [Sat, 27 Apr 2013 08:27:39 +0000 (04:27 -0400)]
pixman/refactor: Delete this file
Essentially all of it is obsolete by now.
Nemanja Lukic [Mon, 15 Apr 2013 17:33:02 +0000 (19:33 +0200)]
MIPS: DSPr2: Added rpixbuf fast path.
Performance numbers before/after on MIPS-74kc @ 1GHz:
lowlevel-blt-bench results
Referent (before):
rpixbuf = L1: 14.63 L2: 13.55 M: 9.91 ( 79.53%) HT: 8.47 VT: 8.32 R: 8.17 RT: 4.90 ( 33Kops/s)
Optimized:
rpixbuf = L1: 45.69 L2: 37.30 M: 17.24 (138.31%) HT: 15.66 VT: 14.88 R: 13.97 RT: 8.38 ( 44Kops/s)
Nemanja Lukic [Mon, 15 Apr 2013 17:33:01 +0000 (19:33 +0200)]
MIPS: DSPr2: Added pixbuf fast path.
Performance numbers before/after on MIPS-74kc @ 1GHz:
lowlevel-blt-bench results
Referent (before):
pixbuf = L1: 18.18 L2: 16.47 M: 13.36 (107.27%) HT: 10.16 VT: 10.07 R: 9.84 RT: 5.54 ( 35Kops/s)
Optimized:
pixbuf = L1: 43.54 L2: 36.02 M: 17.08 (137.09%) HT: 15.58 VT: 14.85 R: 13.87 RT: 8.38 ( 44Kops/s)
Nemanja Lukic [Mon, 15 Apr 2013 17:33:00 +0000 (19:33 +0200)]
test: add "pixbuf" and "rpixbuf" to lowlevel-blt-bench
Add necessary support to lowlevel-blt benchmark for benchmarking pixbuf and
rpixbuf fast paths. bench_composite function now checks for pixbuf string in
testname, and if that is detected, use same bits for src and mask images.
Nemanja Lukic [Mon, 15 Apr 2013 17:32:59 +0000 (19:32 +0200)]
test: add "src_0888_8888_rev" and "src_0888_0565_rev" to lowlevel-blt-bench