bytes instead
of bits. This way 16-bit and 64-bit per color component will be
also supported. The limitation of this approach is that the depth
of every color component has to be a multiple of 8 bits if any of
them is 16 bits or larger.
I don't feel very comfortable about the fact that some app
would be great if your patches first got an approval in the form of
Acked-by or Reviewed-by from at least one person other than you.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/m
)
> {
> +pixel_checker_require_uint32_format(checker);
> +
> get_limits (checker, DEVIATION, color, am, rm, gm, bm);
> }
>
> @@ -2085,6 +2124,8 @@ void
> pixel_checker_get_min (const pixel_checker_t *checker, color_t *color,
>
is really urgent). Not everyone constantly monitors
the mailing list and is able to provide an instant response.
Thanks!
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman
re or
a problem detected by the test suite. Then we would need to look at
this shit and add more checks/workarounds as needed.
I think that the older patch for this issue is somewhat cleaner
because it limits the use of vector extensions to just GCC rather
than trying to satisfy bo
\
> LOAD_VECTOR(source); \
Thanks!
Reviewed-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
But can we have some sort of a commit message with a brief summary?
With some information about how the problem exhibited itself.
Also by following
On Mon, 18 Sep 2017 07:24:49 -0700
Rob Tsuk <r...@tsuk.com> wrote:
> > On Sep 17, 2017, at 6:40 AM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com> wrote:
> >
> > On Mon, 7 Aug 2017 07:52:29 -0700
> > Rob Tsuk <r...@tsuk.com &l
4 now supports "shift vector by scalar"
operation in its vector extension too and could pass the old
incomplete variant of the configure check, but failed to compile
pixman.
Reviewed-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
[Siarhei: update commit message, use resul
-by: Emil Velikov <emil.l.veli...@gmail.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
configure.ac| 1 +
pixman/pixman.c | 12
2 files changed, 13 insertions(+)
diff --git a/configure.ac b/configure.ac
index e833e45..a592cba 100644
--- a/
;
> Any help would be appreciated.
Looks like the MMX switch somehow enforces 32-bit mode for this
particular file. You can try to disable MMX because it is optional for
pixman and does not affect its functionality in any way.
Maybe it's even a good idea to have MMX off by default in Makefile.win32
but t
be great to use the result of
__builtin_shuffle() in the intermediate calculations just in
case. See
https://cgit.freedesktop.org/pixman/commit/?id=a566f627dbd6ea8f2cba70a446e62caaa2ecbd26
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
uri tell us more about his dynamic load/reload use case? So far
I'm not aware of anyone doing this in practice.
Maybe the right solution is to add explicit pixman_init() and
pixman_destroy() functions. But we need to support existing
applications too and we can't expect them
On Thu, 6 Oct 2016 11:32:00 +0100
Peter TB Brett <pe...@peter-b.co.uk> wrote:
> On 06/10/2016 05:25, Siarhei Siamashka wrote:
> > On Mon, 26 Sep 2016 10:46:50 +0100
> > Peter TB Brett <pe...@peter-b.co.uk> wrote:
> >
> >> When compiling
e MSVC compiler for compiling
pixman.
Also if some other Windows user can confirm the bug and test your
fix, that would be perfect.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
/* dest_x */,
> + 0 /* dest_y */,
> + 525 /* width */,
> + 32/* height */);
> +return 1;
> +}
> +
> +int
> +main (int argc, const char *argv[])
> +{
> +
On Sun, 22 May 2016 14:52:13 +0300
Oded Gabbay wrote:
> Hi All,
>
> Due to unexpected turn of events, I'm changing my work focus for the
> foreseeable future.
>
> As a result, I'm sorry to say I will stop contributing to the pixman
> community as a developer/maintainer
On Tue, 17 May 2016 17:32:00 -0700
Khem Raj wrote:
> Some architectures e.g. nios2 do not support all exceptions
>
> Signed-off-by: Khem Raj
> ---
> test/utils.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/test/utils.c b/test/utils.c
>
Hi James,
On Sun, 5 Jun 2016 12:39:46 -0600
James S wrote:
> Hi,
>
> I am learning about coding in a terminal environment. I found pixman and
> am hoping to learn more about it. In building the code it configures
> fine. On issuing the make command I get the following
ild infrastructure.
If I understand it correctly, you are basically trying to go an
extra mile to remove the existing diagnostic interface from the
pixman shared library. Would we lose anything if we just keep
things working as they are?
[1] https://patchwork.freedesktop.org/patch/70676/
--
B
bug.cgi?id=94769
Reported-by: Håvard Eidnes <havard.eid...@gmail.com>
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
pixman/pixman-vmx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/pixman/pixman-vmx.c b/pixman/pixman-vmx.c
index 4
-
> > pixman/pixman-arm-neon-asm-bilinear.h | 165 +++
> > pixman/pixman-arm-neon-asm.S | 280
> > +++--
> > pixman/pixman-arm-neon-asm.h | 20 +++
m
> >
> > .macro pixman_composite_src_x888__init
> > -vmov.u8 q2, #0xFF
> > - vshl.u32 q2, q2, #24
> > +vmov.u32 q2, #0xFF00
> > .endm
> >
> > generate_composite_function \
> > --
> > 1.7.5.4
> >
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
4)
> -lsl DUMMY, W, #dst_bpp_shift
> -sub DST_W, DST_W, DUMMY
> +sub DST_W, DST_W, W, lsl #dst_bpp_shift
> .endif
> .if (src_bpp != 24) && (src_bpp != 0)
> -lsl DUMMY, W, #src_bpp_shift
> -sub SRC, SRC, DUMMY
> +sub SRC, SRC, W, lsl #src_bpp_shift
> .endif
> .if (mask_bpp != 24) && (mask_bpp != 0)
> -lsl DUMMY, W, #mask_bpp_shift
> -sub MASK, MASK, DUMMY
> +sub MASK, MASK, W, lsl #mask_bpp_shift
> .endif
> subsH, H, #1
> mov DST_R, DST_W
>
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
this discussion (mostly
the same questions are getting repeated multiple times), I have also
created the following wiki page with the hope to keep the relevant
information more structured:
https://pixman.miraheze.org/wiki/AArch64_Support
I'll try to add more info
Either way, we are very likely just going to see that reducing the
number of redundant instructions has a positive impact on performance.
In a pretty much similar way as on Cortex-A53.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
but we will
never know until we try.
This can help to identify an optimal bilinear scaling strategy. And
also decide which parts of the existing 32-bit ARM assembly code are
worth converting to AArch64.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
ed runtime detection and multiple
implementations). It would be also great to have your new iterators
framework eventually shared between ARM, x86 and other architectures
to avoid unnecessary code duplication.
Thanks for you work.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
, a
clever hack in the optimized code could be able to deduct
that the matrix is in fact indistinguishable from the
identity tranformation. Which would be an undesired effect
and an opportunity to 'rig' benchmark scores.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
test/lo
e. I only see that just a
few minor tweaks are needed and it will be good enough for pushing
to git. But if I'm mistaken and something is actually difficult,
then you don't need to spend too much time on it. Thanks.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pixman
> were
> renamed not to cause confliction.
We still can do the same labels rename in the 32-bit assembly source.
This will allow us to reduce the difference between 32-bit and 64-bit
assembly sources.
> Anyway, I'll post new (simplified) patch again.
Thanks. But maybe first try to remov
t too. I will not go into the details right now (we can
discuss it later), but this 'pixman-arma64-neon-asm-bilinear.S'
file is much less important and we probably don't care much
about optimizing it well.
This post has already got rather long, so I'll stop here for now.
Does anyone hav
\s+[^,]+,[^,]+,[^,]+,\s*)asl(\s+\#)/, '\1lsl\2')
puts l
end
The source files are assembled into exactly the same object files
after this change.
Signed-off-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
---
pixman/pixman-arm-neon-asm-bilinear.S | 98 --
McCloskey <wmcclos...@mozilla.com> wrote:
> This test ensures that calling _intersect_rect on an empty
> rectangle produces an empty region.
>
> Reviewed-by: Siarhei Siamashka <siarhei.siamas...@gmail.com>
Your "Signed-off-by: Bill McCloskey <wmcclos...@mozilla.com>&qu
t there had been many compiler bugs
affecting pixman during the last few years. Now you are dealing
with uncommon architectures, and the compilers there are probably
even less mature than GCC on x86 / arm / powerpc.
--
Best regards,
Siarhei Siamashka
em about the pixman package upgrade.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
On Wed, 18 Nov 2015 14:22:09 -0800
Matt Turner <matts...@gmail.com> wrote:
> On Sun, Oct 11, 2015 at 10:34 AM, Andrea Canciani <ranm...@gmail.com> wrote:
> > On Sun, Oct 11, 2015 at 5:30 AM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com> wrote:
> >&g
On Mon, 26 Oct 2015 02:10:39 +0200
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Sun, 25 Oct 2015 13:13:09 -0700
> Matt Turner <matts...@gmail.com> wrote:
>
> > On Sun, Oct 11, 2015 at 8:59 PM, Matt Turner <matts...@gmail.com> wrote:
>
ble though. Been there, done that with ARMv6.
Or we could simply do nothing and finally retire MMX support on x86.
If OLPC XO-1 users still do exist, they can always contact us.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
\
> - \
> - asm ("pshufw %2, %1, %0\n\t" \
> - : "=y" (ret) \
> - : "
\
> - \
> - ret;\
> -})
> -# endif
> -# endif
> -#endif
> -
> #ifndef _MSC_VER
> #define _MM_SHUFFLE(fp3,fp2,fp1,fp0) \
> (((fp3) << 6) | ((fp2) << 4) | ((fp1) << 2) | (fp0))
The _MM_SHUFFLE define can be removed because it triggers some warnings
if is included:
pixman-mmx.c(64): warning #47: incompatible redefinition of macro "_MM_SHUFFLE"
(declared at line 96 of
"/opt/intel/composerxe-2013.0.080/compiler/include/xmmintrin.h")
#define _MM_SHUFFLE(fp3,fp2,fp1,fp0) \
^
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
ly what we need here. Because the PSHUFW instruction
expects an integer constant as the third operand.
> I think a simple (albeit not quite elegant) fix would be to just use X
> instead of K.
The "X" constraint is not a correct fix because it's a wrong constraint.
If the operand happen
On Sun, 11 Oct 2015 04:53:08 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Sat, 10 Oct 2015 16:03:53 -0700
> Jeremy Huddleston Sequoia <jerem...@freedesktop.org> wrote:
>
> > > On Oct 10, 2015, at 13:48, Andrea Canciani <ranm...@gmail.com>
On Fri, 25 Sep 2015 14:38:46 +0300
Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 25 Sep 2015 07:38:34 +0300
> Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
>
> > On Wed, 23 Sep 2015 11:40:32 +0300
> > Pekka Paalanen <ppaala...@gmail.com> w
On Tue, 22 Sep 2015 13:54:54 +0100
"Ben Avison" <bavi...@riscosopen.org> wrote:
> On Mon, 21 Sep 2015 06:32:48 +0100, Siarhei Siamashka
> <siarhei.siamas...@gmail.com> wrote:
> > Since we are trying to justify the 8e extra safety margin removal in
> > t
Sat, Sep 5, 2015 at 10:03 PM, Oded Gabbay <oded.gab...@gmail.com>
> >> > > wrote:
> >> > > >
> >> > > > On Fri, Sep 4, 2015 at 3:39 PM, Siarhei Siamashka
> >> > > > <siarhei.siamas...@gmail.com> wrote:
> >> >
sform the lower coordinate and add (size-1)
> steps of the increment in source coordinate space. No projective
> transform routines use the COVER_CLIP flags, so they cannot be affected.
>
> Proof by Siarhei Siamashka:
>
> Let's take a look at the following affine transformat
On Mon, 21 Sep 2015 21:34:51 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> Siarhei Siamashka <siarhei.siamas...@gmail.com> skribis:
>
> > Sorry, I forgot to mention
> > http://cgit.freedesktop.org/pixman/tree/README?id=pixman-0.33.2#n46
> >
> >
h <= 0" check to the patch?
Best regards,
Siarhei Siamashka
> On Sep 21, 2015 3:07 PM, "Siarhei Siamashka" <siarhei.siamas...@gmail.com>
> wrote:
>
> > On Mon, 21 Sep 2015 17:10:36 +0200
> > l...@gnu.org (Ludovic Courtès) wrote:
> >
> > &
quot;.
> The bug can most likely lead to a crash.
Yes, I can confirm that the bug is reproducible on my x86-64 system:
export CFLAGS="-O2 -m32" && ./autogen.sh
./configure --disable-libpng --disable-gtk && make
setarch i686 -R test/stress-test
&&
> - pixman_fixed_to_int (transformed.x2) < image->bits.width&&
> - pixman_fixed_to_int (transformed.y2) < image->bits.height)
> + if (pixman_fixed_to_int (transformed.x1 - pixman_fixed_e) >= 0
> &&
>
On Mon, 21 Sep 2015 08:32:48 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> On Fri, 11 Sep 2015 14:30:23 +0300
> Pekka Paalanen <ppaala...@gmail.com> wrote:
>
> > From: Ben Avison <bavi...@riscosopen.org>
> >
> > As discussed in
>
On Fri, 18 Sep 2015 13:39:52 +0300
Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 18 Sep 2015 08:36:09 +0300
> Oded Gabbay <oded.gab...@gmail.com> wrote:
>
> > On Fri, Sep 18, 2015 at 6:08 AM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com&
cgit.freedesktop.org/pixman/commit/?id=61d999b9101c76bd463101923d2143e31857e7f8
http://cgit.freedesktop.org/pixman/commit/?id=8f75f638ab03078546cc89edfbec4f6801b77e5e
I suspect that either your version of pixman is too old or your clang
is too old. Or maybe even both of them are too old.
--
Bes
x$have_sys_time_h = xyes; then
> diff --git a/test/utils.c b/test/utils.c
> index 222d4d5..8657966 100644
> --- a/test/utils.c
> +++ b/test/utils.c
> @@ -966,9 +966,11 @@ enable_divbyzero_exceptions (void)
> {
> #ifdef HAVE_FENV_H
> #ifdef HAVE_FEENABLEEXCEPT
> +#ifdef HAVE_FEDIVBYZERO
>
ki/POWER8 mentions 16MB of L4 cache.
One the other hand, ~200 MPix/s is a relatively low bandwidth by the
high performance desktop/server standards and should not be a problem
for the automatic hardware prefetch.
--
Best regards,
Siarhei Siamashka
___
Pixman m
gt; -
> >> - ms = unpack_32_1x128 (s);
> >> - ms = pix_multiply (ms, mm);
> >> -
> >> - s = pack_1x128_32 (ms);
> >> -}
> >> + UN8x4_MUL_UN8(s, a);
> >>
> >> return s;
> >> }
> >
> > Thanks,
> > pq
>
> Thanks for catching that!
Indeed, that was a good catch.
The problem does not get detected by the test suite because this
memory access is optimized out by the compiler. But if we disable
optimizations by setting CFLAGS to "-O0", then the 'scaling-test'
program segfaults. It means that we at least don't have a test
coverage problem here.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
_t arm_simd_fast_paths[] =
> SIMPLE_NEAREST_FAST_PATH (SRC, x8b8g8r8, x8b8g8r8, armv6__),
>
> { PIXMAN_OP_NONE },
> +
> +PIXMAN_STD_FAST_PATH (OVER, solid, null, a8r8g8b8,
> armv6_composite_over_n_),
> +PIXMAN_STD_FAST_PATH (OVER, solid, nu
aster -> master
Well, nothing bad has really happened yet. But probably it would be
great to give at least a 2 days notice before pushing patches, unless
they had been actually reviewed by somebody.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
;> >
> >>
> >> It bugged me that there was no change, neither up nor down in cairo
> >> benchmark.
> >> So I rechecked it and I had a wrong setup - cairo used the system-installed
> >> pixman instead of my pixman.
> >>
> >> After fixing that
On Thu, 10 Sep 2015 12:27:18 +0300
Oded Gabbay <oded.gab...@gmail.com> wrote:
> On Sat, Sep 5, 2015 at 10:03 PM, Oded Gabbay <oded.gab...@gmail.com> wrote:
> >
> > On Fri, Sep 4, 2015 at 3:39 PM, Siarhei Siamashka
> > <siarhei.siamas...@gmail.com> w
Running "lowlevel-blt-bench over_n_" on Playstation3 3.2GHz,
Gentoo ppc (32-bit userland) gave the following results:
before: over_n_ = L1: 147.47 L2: 205.86 M:121.07
after: over_n_ = L1: 287.27 L2: 261.09 M:133.48
Signed-off-by: Siarhei Siamashka <s
On Fri, 4 Sep 2015 15:39:00 +0300
Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote:
> Running "lowlevel-blt-bench over_n_" on Playstation3 3.2GHz,
> Gentoo ppc (32-bit userland) gave the following results:
>
> before: over_n_ = L1: 147.47
on in almost all the benches (on
> POWER8, ppc64le):
>
> reference memcpy speed = 24764.8MB/s (6191.2MP/s for 32bpp fills)
> L1 572.29 676.6 +18.23%
> L2 1038.08 672.68-35.20%
> M 1104.1 682.63-38.17%
> HT 447.
On Thu, 3 Sep 2015 13:53:26 +0300
Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Thu, 27 Aug 2015 11:45:22 +0100
> "Ben Avison" <bavi...@riscosopen.org> wrote:
>
> > On Thu, 27 Aug 2015 03:55:07 +0100, Siarhei Siamashka
> > <siarhei.siamas...@gmai
nt in practice.
But in the case of BILINEAR scaling, the new 'cover-test' is indeed
very useful and represents a nice addition to the test suite. Thanks
for doing this work.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
getting inspired
by this discussion thread and going on a crusade against the two's
complement signed integer representation assumptions.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http
.
{
*flags |= FAST_PATH_SAMPLES_COVER_CLIP_BILINEAR;
}
I believe that neither of FAST_PATH_SAMPLES_COVER_CLIP_NEAREST and
FAST_PATH_SAMPLES_COVER_CLIP_BILINEAR flags matters for projective
transformations, but this can be additionally checked just in case.
--
Best regards,
Siarhei
public.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
remain unnoticed even
when using the pixman's own benchmarking tools. But thanks for posting
the x11perf numbers. They are also interesting.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http
= vmx_fill;
return imp;
Still because the vmx_composite_copy_area benchmarks show a
performance improvement in practice (even with less than perfect
unaligned loads handling on big endian systems), I see no reasons
to complain. So
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
( 148Kops/s)
== after ==
src__ = L1: 850.60 L2: 453.91 M:174.26 (265.31%)
HT:105.68 VT: 54.17 R: 54.88 RT: 18.72 ( 154Kops/s)
Assuming that the commit message gets updated,
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei
: do pix_multiply for two vectors (separately)
- over_2x128 : perform over op. on two vectors
- in_over_2x128 : perform in-over op. on two vectors
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Just one question
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
: 1.06x
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
533.92 - 474.50 : 1.13x
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org
-gfx 1488.59 - 1209.19 : 1.23x
Slowdowns
=
t-evolution 553.88 - 581.63 : 1.05x
t-poppler 364.99 - 383.79 : 1.05x
t-firefox-scrolling 1223.65 - 1304.34 : 1.07x
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas
=
t-poppler 364.99 - 393.72 : 1.08x
t-firefox-canvas-alpha 984.55 - 1197.85 : 1.22x
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
/s)
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
today.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
is ignored when applying it.
Hello.
In the v2 of the patch, I tried to address some concerns, raised by Siarhei
Siamashka.
One that I was not sure of how to treat was the vec_perm within splat_alpha
function. It does not look all pretty, but it will work regardless of the
endianness.
Yes
/?id=795db042f44a12147de7449f47da901670733f71
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
: inform
- @$(RM) $(CFG_VAR)/*.{exe,ilk,lib,obj,pdb} $(BUILT_SOURCES) || exit 0
+ @-$(call rm,$(CFG_VAR)/*.exe $(CFG_VAR)/*.ilk $(CFG_VAR)/*.lib
$(CFG_VAR)/*.obj $(CFG_VAR)/*.pdb} $(BUILT_SOURCES))
.PHONY: inform clean
--
Best regards,
Siarhei Siamashka
(+), 82 deletions(-)
This looks like a nice code cleanup to me (46 lines removed). It is
still possible that the NORMAL repeat may need special tuning later,
but this is not a good reason to prevent unification now.
The whole set is
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
--
Best
and
ensure that nothing fails. It can be run as make check in Linux,
but I'm not sure about how to best do this in Windows. If you are using
MinGW, then MSYS can probably provide a Unix-like shell where you just
type ./configure make make check to get everything done.
--
Best regards,
Siarhei Siamashka
and
it just hasn't been hit until now? There is test/fuzzer-find-diff.pl
that can be used to find out the particular iteration that fails.
The bugs can be never ruled out completely, but in this case it is
unlikely.
--
Best regards,
Siarhei Siamashka
___
Pixman
## source,\
+splat_alpha (v ## mask));
#define STORE_VECTOR(dest) \
vec_st ((vector unsigned int) v ## dest, 0, dest);
--
Best regards,
Siarhei Siamashka
On Mon, 25 May 2015 21:43:38 -0400
Fernando Seiti Furusato ferse...@linux.vnet.ibm.com wrote:
Also, Siarhei Siamashka mentioned it would be good if I demonstrated that it
also does not affect ppc in 32-bit mode. I am not sure on how to do so. Any
suggestions?
It is possible to use the -m32
,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
to detect unexpected changes in behaviour, and
does not really test if the clipping is actually done correctly. This
surely could be improved.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org
regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
On Tue, 2 Dec 2014 07:53:38 +0200
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
On Mon, 1 Dec 2014 23:46:43 +
Andrea Giammarchi andrea.giammar...@gmail.com wrote:
On Mon, Dec 1, 2014 at 8:48 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Mon, 1 Dec 2014 10
.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
fast.
Tools like C-Reduce can be used for finding a smaller testcase when
debugging internal compiler error problems:
http://embed.cs.utah.edu/creduce/
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
Pixman@lists.freedesktop.org
http
On Mon, 1 Dec 2014 23:46:43 +
Andrea Giammarchi andrea.giammar...@gmail.com wrote:
On Mon, Dec 1, 2014 at 8:48 PM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Mon, 1 Dec 2014 10:12:05 +
Andrea Giammarchi andrea.giammar...@gmail.com wrote:
Hello there,
I
Using --disable-sse2 --disable-ssse3 configure options and
CFLAGS=-m32 -O2 -g on an x86 system results in pixman make check
failures:
../test-driver: line 95: 29874 Aborted
FAIL: affine-test
../test-driver: line 95: 29887 Aborted
FAIL: scaling-test
One _mm_empty () was missing
discussed it before. Maybe we should just disable
MMX support for x86 and use it only for MIPS Loongson and ARM IWMMXT?
It does not look like https://gcc.gnu.org/PR47759 is going to be ever
fixed.
--
Best regards,
Siarhei Siamashka
___
Pixman mailing list
1 - 100 of 459 matches
Mail list logo