On Mon, 25 May 2015 21:43:38 -0400
Fernando Seiti Furusato 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" gcc option to build 32-bi
On Mon, 25 May 2015 21:43:39 -0400
Fernando Seiti Furusato wrote:
> I have made some changes to the file pixman-vmx.c, which uses vmx (aka
> altivec)
> to optimize pixman. Basically, what I did:
> Changed the usage of vec_perm, vec_mergeh and vec_mergel. They were giving
> weird results when ru
On Tue, May 26, 2015 at 3:58 PM, Ben Avison wrote:
> This test aims to verify both numerical correctness and the honouring of
> array bounds for scaled plots (both nearest-neighbour and bilinear) at or
> close to the boundary conditions for applicability of "cover" type fast paths
> and iter fetch
This test aims to verify both numerical correctness and the honouring of
array bounds for scaled plots (both nearest-neighbour and bilinear) at or
close to the boundary conditions for applicability of "cover" type fast paths
and iter fetch routines.
It has a secondary purpose: by setting the env v
---
pixman/pixman-mmx.c | 20
pixman/pixman-sse2.c | 20
2 files changed, 8 insertions(+), 32 deletions(-)
diff --git a/pixman/pixman-mmx.c b/pixman/pixman-mmx.c
index 42826d9..877b6e9 100644
--- a/pixman/pixman-mmx.c
+++ b/pixman/pixman-mmx.c
@@ -40
This macro does exactly the same thing as the platform-neutral macro
SIMPLE_NEAREST_FAST_PATH.
---
This is one of a number of (independent) patches arising from a survey of
scaled fast paths which highlighted the fact that the fast path table
macros could be consolidated somewhat.
pixman/pixman-a
This macro is a superset of the platform-neutral macro
SIMPLE_NEAREST_A8_MASK_FAST_PATH. In other words, in addition to the
_COVER, _NONE and _PAD suffixes, its expansion includes the _NORMAL suffix.
---
pixman/pixman-arm-common.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff
These two architectures were the only place where
SIMPLE_NEAREST_SOLID_MASK_FAST_PATH was used, and in both cases the
equivalent SIMPLE_NEAREST_SOLID_MASK_FAST_PATH_NORMAL macro was used
immediately afterwards, so including the NORMAL case in the main macro
simplifies the fast path table.
---
pixm
Sorry folks, typo in subject line, should read
mmx/sse2: Use SIMPLE_NEAREST_FAST_PATH macro
Ben
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
This macro does exactly the same thing as the platform-neutral macro
SIMPLE_NEAREST_A8_MASK_FAST_PATH.
---
Question for anyone who can test this code: can working NORMAL repeat
versions of these operations (over__8_0565 and over_0565_8_0565) be
added reasonably easily? This would enable the sam
---
Hi Fernando,
solid-test is a very new test, and you're quite possibly the first person
to try it on any big-endian machine. Can you try this variation and see if
it helps please?
Thanks,
Ben
test/solid-test.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/t
On 05/26/2015 09:46 AM, Fernando Seiti Furusato wrote:
Below is the one that failed on ppc64:
I want to correct myself here.
I was told today that I am running powerpc on 32-bit mode when using ppc BE on
Debian.
I just confused myself because uname -m returned "ppc64".
I apologize for the mist
On 05/26/2015 06:13 AM, Pekka Paalanen wrote:
I'm curious, what is this one test in master that fails on ppc64? And
it really succeeds after your patch on ppc64le?
That's right, I just ran make && make check and got the same result.
Could you provide the test log for that one?
Below is the on
On Mon, 25 May 2015 21:43:38 -0400
Fernando Seiti Furusato wrote:
> Hello L&G.
>
> I will detail prior and post patch for both ppc64le and ppc64 architectures,
> so I can indicate that my patch will not affect either negatively.
> That is because I just noticed that upstream version is now on ve
14 matches
Mail list logo