On Mon, 24 Aug 2015 21:42:04 +0100
Ben Avison wrote:
> In functions named fast_composite_scaled_bilinear... as defined by
> FAST_BILINEAR_MAINLOOP_INT, there are multiple calls to scanline_func
> (a macro parameter) which is often implemented in assembly, and which
> takes as parameters two line
On Mon, 24 Aug 2015 21:42:00 +0100
Ben Avison wrote:
> This patch has no effect upon the way the flags are calculated, but splitting
> it out into a separate patch like this means we can consider the bilinear and
> nearest calculations independently.
> ---
> pixman/pixman.c | 25 --
On Thu, 04 Jun 2015 14:00:30 +0100, Pekka Paalanen wrote:
On Tue, 26 May 2015 23:58:30 +0100
Ben Avison wrote:
+#define SQRT_0POINT5_0POINT32_FIXED (0xB504F334u)
Ok, I checked. Mathematically it is equivalent, but maybe a slightly
more obvious name would be INV_SQRT_2_...?
Fair enough, r
On 08/26/15 09:03 AM, Siarhei Siamashka wrote:
On Wed, 26 Aug 2015 08:46:57 -0700
Alan Coopersmith wrote:
On 08/26/15 08:40 AM, Siarhei Siamashka wrote:
If we start compiling pixman in C99 mode by default, then this will make
it harder for us to identify potential C89 compatibility issues.
On Wed, 26 Aug 2015 08:46:57 -0700
Alan Coopersmith wrote:
> On 08/26/15 08:40 AM, Siarhei Siamashka wrote:
> > If we start compiling pixman in C99 mode by default, then this will make
> > it harder for us to identify potential C89 compatibility issues.
>
> Do we still need to care about C89 com
On 08/26/15 08:40 AM, Siarhei Siamashka wrote:
If we start compiling pixman in C99 mode by default, then this will make
it harder for us to identify potential C89 compatibility issues.
Do we still need to care about C89 compatibility issues? C99 is 16 years old
now, it's about time to rely on
On Wed, 26 Aug 2015 07:34:13 -0700
Alan Coopersmith wrote:
> On 08/26/15 06:21 AM, Ben Avison wrote:
> > No, but I'd have thought it was bad practice to assume C99 behaviour when
> > compiling C89.
>
> Perhaps the AC_PROG_CC_C99 macro should be added to the pixman/configure.ac
> to avoid that th
On 08/26/15 06:21 AM, Ben Avison wrote:
No, but I'd have thought it was bad practice to assume C99 behaviour when
compiling C89.
Perhaps the AC_PROG_CC_C99 macro should be added to the pixman/configure.ac
to avoid that then.
--
-Alan Coopersmith- alan.coopersm...@oracle.co
On Wed, 26 Aug 2015 10:36:06 +0100, Pekka Paalanen wrote:
On Mon, 24 Aug 2015 21:41:59 +0100
Ben Avison wrote:
Towards this goal, the following patches were posted to the list - and they
seem to have escaped Patchwork's notice:
http://lists.freedesktop.org/archives/pixman/2015-May/003644.h
On Wed, 26 Aug 2015 10:22:22 +0100, Siarhei Siamashka
wrote:
On Fri, 14 Aug 2015 15:06:07 +0100
Ben Avison wrote:
The previous implementations of DIV and MOD relied upon the built-in
/ and % operators performing round-to-zero. This is true for C99, but
rounding is implementation-defined for
On Wed, 26 Aug 2015 09:46:49 +0100, Pekka Paalanen wrote:
It's clearly controversial to add C fast paths, because it affects all
targets that don't have an asm fast path for the same, and we cannot
tell by just review whether it is going to be for better or (much)
worse.
Yes, it's always going
On Wed, 26 Aug 2015 00:23:22 +0100
Ben Avison wrote:
> As described in the individual patches, I'm actually suggesting we *don't*
> use this approach, since using general_composite_rect seems to increase the
> overhead so much that it's no longer just L1 tests that show regressions.
> However, I
On Mon, 24 Aug 2015 21:41:59 +0100
Ben Avison wrote:
> Some back story...
>
> First there was this patch:
>
> http://patchwork.freedesktop.org/patch/49937/
>
> Back last October, Søren had this to say about it:
>
> > A concern I have here is that code might access pixels outside the
> > image
On Fri, 14 Aug 2015 15:06:07 +0100
Ben Avison wrote:
> The previous implementations of DIV and MOD relied upon the built-in / and %
> operators performing round-to-zero. This is true for C99, but rounding is
> implementation-defined for C89 when divisor and/or dividend is negative, and
> I believ
On Wed, Aug 26, 2015 at 11:46 AM, Pekka Paalanen wrote:
> On Tue, 25 Aug 2015 15:45:48 +0300
> Oded Gabbay wrote:
>
>> On Mon, Aug 24, 2015 at 7:04 PM, Ben Avison wrote:
>> >
>> > On Mon, 24 Aug 2015 15:20:22 +0100, Oded Gabbay
>> > wrote:
>> >>
>> >> I tested the patch on POWER8, ppc64le.
>>
On Tue, 25 Aug 2015 15:45:48 +0300
Oded Gabbay wrote:
> On Mon, Aug 24, 2015 at 7:04 PM, Ben Avison wrote:
> >
> > On Mon, 24 Aug 2015 15:20:22 +0100, Oded Gabbay
> > wrote:
> >>
> >> I tested the patch on POWER8, ppc64le.
> >> make check passes, but when I benchmarked the performance using
>
On Tue, Aug 25, 2015 at 3:45 PM, Oded Gabbay wrote:
> I think the more immediate solution, as Soren have suggested on IRC,
> is for me to implement the equivalent fast-path in VMX.
Siarhei,
I wanted to apologize. I accidentally thought ssvb in IRC is Soren
instead of you, so that's why I mentione
17 matches
Mail list logo
