Re: [Pixman] [PATCH 1/2] pixman: Add support for argb/xrgb float formats, v3.

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

Re: [Pixman] [PATCH 2/2] pixman: Add tests for xrgb/argb formats.

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

Re: [Pixman] [PATCH v2] pixman: Add support for argb/xrgb float formats

) > { > +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, >

[Pixman] Pushing unreviewed patches to the pixman git repository

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: [Pixman] [PATCH] test: Adjust for clang's removal of __builtin_shuffle

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

Re: [Pixman] [PATCH] vmx: Fix vector loads on ppc64le

\ > 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

Re: [Pixman] Patch to fix test for GCC vector extensions

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

[Pixman] [PATCH] configure.ac: Fix false GCC vector extensions detection for Clang 4

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

[Pixman] [PATCH] Add destructor function to free pixman_implementation_t structs on exit

-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/

Re: [Pixman] pixman 0.34.0 win64 compilation issue

; > 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

Re: [Pixman] Patch to fix test for GCC vector extensions

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

Re: [Pixman] [BUG REPORT] pixman_glyph_cache_create leaks memory that it allocates

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

Re: [Pixman] [PATCH] build: Ensure config.h does not undefine `sqrtf`

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

Re: [Pixman] [PATCH] build: Ensure config.h does not undefine `sqrtf`

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

Re: [Pixman] [PATCH] Trying to reproduce bug #97938

/* dest_x */, > + 0 /* dest_y */, > + 525 /* width */, > + 32/* height */); > +return 1; > +} > + > +int > +main (int argc, const char *argv[]) > +{ > +

Re: [Pixman] Leaving maintainer role

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

Re: [Pixman] [PATCH] test/utils: Check for FE_INVALID definition before use

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 >

Re: [Pixman] Bug Report on Linux From Scratch

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

Re: [Pixman] [PATCH 1/4] test: static link pixman in matrix-test

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

[Pixman] [PATCH] vmx: Fix scaled_nearest_scanline_vmx_8888_8888_OVER for GCC 4.5

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

Re: [Pixman] [PATCH 0/9] Changes to existing ARMv7 routines

- > > pixman/pixman-arm-neon-asm-bilinear.h | 165 +++ > > pixman/pixman-arm-neon-asm.S | 280 > > +++-- > > pixman/pixman-arm-neon-asm.h | 20 +++

Re: [Pixman] [PATCH 4/9] armv7: Simplify constant load

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

Re: [Pixman] [PATCH] pixman: Add support for aarch64 neon optimization (ver.3.1)

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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

[Pixman] [PATCH] lowlevel-blt-bench: horizontal/vertical variants of bilinear scaling

, 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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

> 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

Re: [Pixman] [PATCH] Add support for aarch64 neon optimization

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

[Pixman] [PATCH] ARM: NEON: Use AArch64 compatible syntax for barrel shifter arguments

\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 --

Re: [Pixman] [PATCH 1/2] Add test for _intersect_rect(, )

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

Re: [Pixman] [PATCH] configure: add options to disable demos and tests

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

Re: [Pixman] Pixman Digest, Vol 71, Issue 13

em about the pixman package upgrade. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] Pixman not building on MacOS X 10.11

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

Re: [Pixman] [PATCH] mmx: Use MMX2 intrinsics from xmmintrin.h directly.

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: >

Re: [Pixman] [PATCH] mmx: Use MMX2 intrinsics from xmmintrin.h directly.

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

Re: [Pixman] [PATCH] mmx: Use MMX2 intrinsics from xmmintrin.h directly.

\ > - \ > - asm ("pshufw %2, %1, %0\n\t" \ > - : "=y" (ret) \ > - : "

Re: [Pixman] [PATCH] mmx: Use MMX2 intrinsics from xmmintrin.h directly.

\ > - \ > - 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

Re: [Pixman] Pixman not building on MacOS X 10.11

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

Re: [Pixman] Pixman not building on MacOS X 10.11

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>

Re: [Pixman] [PATCH v3 1/2] Remove the 8e extra safety margin in COVER_CLIP analysis

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

Re: [Pixman] [PATCH 1/2] Remove the 8e extra safety margin in COVER_CLIP analysis

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

Re: [Pixman] [PATCH] vmx: implement fast path vmx_composite_over_n_8888

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: > >> >

Re: [Pixman] [PATCH v3 1/2] Remove the 8e extra safety margin in COVER_CLIP analysis

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

Re: [Pixman] [PATCH] Fix arithmetic overflow in pointer arithmetic in ‘general_composite_rect’

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 > > > >

Re: [Pixman] [PATCH] Fix arithmetic overflow in pointer arithmetic in ‘general_composite_rect’

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: > > > > &

Re: [Pixman] [PATCH] Fix arithmetic overflow in pointer arithmetic in ‘general_composite_rect’

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

Re: [Pixman] [PATCH 1/2] Remove the 8e extra safety margin in COVER_CLIP analysis

&& > - 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 > && >

Re: [Pixman] [PATCH 1/2] Remove the 8e extra safety margin in COVER_CLIP analysis

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 >

Re: [Pixman] Pixman release schedule

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&

Re: [Pixman] Fwd: pixman clang issue

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

Re: [Pixman] [PATCH] [v3] test: add a check for FE_DIVBYZERO

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 >

Re: [Pixman] [PATCH 1/4] vmx: optimize scaled_nearest_scanline_vmx_8888_8888_OVER

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

Re: [Pixman] [PATCH 1/4] vmx: optimize scaled_nearest_scanline_vmx_8888_8888_OVER

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

Re: [Pixman] [PATCH v2 1/2] armv6: Add over_n_8888 fast path (disabled)

_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

Re: [Pixman] [PATCH v2 0/2] over_n_8888 fast path for RaspberryPi

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

Re: [Pixman] [PATCH 0/4] More VMX enhancements

;> > > >> > >> 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

Re: [Pixman] [PATCH] vmx: implement fast path vmx_composite_over_n_8888

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

[Pixman] [PATCH] vmx: implement fast path vmx_composite_over_n_8888

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

Re: [Pixman] [PATCH] vmx: implement fast path vmx_composite_over_n_8888

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

Re: [Pixman] [PATCH 1/4] pixman-fast-path: Add over_n_8888 fast path (disabled)

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.

Re: [Pixman] [PATCH 1/7] Refactor calculation of cover flags

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

Re: [Pixman] [PATCH] test: Add cover-test

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

Re: [Pixman] [PATCH] Resolve implementation-defined behaviour for division rounded to -infinity

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

Re: [Pixman] [PATCH 1/7] Refactor calculation of cover flags

. { *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

Re: [Pixman] [PATCH 5/7] armv7/mips/sse2: Fix bounds violations in bilinear cover scaled fast paths

public. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 00/12] Implement more vmx fast paths

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

Re: [Pixman] [PATCH 04/12] vmx: implement fast path vmx_blt

= 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

Re: [Pixman] [PATCH 05/12] vmx: implement fast path vmx_composite_copy_area

( 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

Re: [Pixman] [PATCH 02/12] vmx: add helper functions

: 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

Re: [Pixman] [PATCH 03/12] vmx: implement fast path vmx_fill

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

Re: [Pixman] [PATCH 09/12] vmx: implement fast path scaled nearest vmx_8888_8888_OVER

: 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

Re: [Pixman] [PATCH 08/12] vmx: implement fast path vmx_composite_src_x888_8888

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

Re: [Pixman] [PATCH 06/12] vmx: implement fast path vmx_composite_over_n_8888_8888_ca

-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

Re: [Pixman] [PATCH 07/12] vmx: implement fast path vmx_composite_over_n_8_8888

= 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

Re: [Pixman] [PATCH 11/12] vmx: implement fast path iterator vmx_fetch_r5g6b5

/s) -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 12/12] vmx: implement fast path iterator vmx_fetch_a8

-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

Re: [Pixman] [PATCH 1/3] vmx: implement fast path composite_over_8888_8888

Siamashka siarhei.siamas...@gmail.com -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 2/3] vmx: implement fast path composite_add_8_8

Siamashka siarhei.siamas...@gmail.com -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 3/3] vmx: implement fast path composite_add_8888_8888

-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

Re: [Pixman] [PATCH 00/12] Implement more vmx fast paths

today. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH 1/1 v2] vmx: workarounds to fix powerpc little endian particularities

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

Re: [Pixman] RFC: Pixman benchmark CPU time measurement

/?id=795db042f44a12147de7449f47da901670733f71 -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] [PATCH] Allow building on Windows with cmd.exe

: 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

Re: [Pixman] Going to land (Re: [PATCH] mmx/sse2: Use SIMPLE_NEAREST_SOLID_MASK_FAST_PATH for NORMAL repeat)

(+), 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

Re: [Pixman] bug in pixman 0.30 ??

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

Re: [Pixman] [RFC PATCH] solid-test: Allow for big-endian targets

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

Re: [Pixman] [PATCH 1/1] pixman: Fixing endianness problems for powerpc archs

## source,\ +splat_alpha (v ## mask)); #define STORE_VECTOR(dest) \ vec_st ((vector unsigned int) v ## dest, 0, dest); -- Best regards, Siarhei Siamashka

Re: [Pixman] [PATCH 0/1] pixman: Fixing endianness problems for powerpc archs

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

Re: [Pixman] Help with sending patch

, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] Source clipping: how-to and tests

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

Re: [Pixman] Documentation is incorrect

regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] Unable to build master on Raspberry PI

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

Re: [Pixman] Missing symbols prng_state and prng_state_data

. -- Best regards, Siarhei Siamashka ___ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman

Re: [Pixman] Unable to build master on Raspberry PI

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

Re: [Pixman] Unable to build master on Raspberry PI

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

[Pixman] [PATCH] mmx: Fix _mm_empty problems for over_8888_8888/over_8888_n_8888

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

Re: [Pixman] [PATCH 0/2] mmx nearest scaling paths

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   2   3   4   5   >