Thanks Alan, I would try with that option. Hopefully we would not came across
any functions actually invoke SSSE3 supported feature.
Best Regards
Yike
-Original Message-
From: Alan Coopersmith [mailto:alan.coopersm...@oracle.com]
Sent: Tuesday, April 05, 2016 10:01 AM
To: Yike Zhang;
On 04/ 4/16 06:51 PM, Yike Zhang wrote:
Hi Alan,
Thanks so much for your promptly response. Based on your valuable input, I find
the following RN
http://www.c0t0d0s0.org/archives/4974-Whats-new-in-Solaris-10-1008-also-known-as-Update-6.html
and
x86: Kernel Support for Intel SSSE3, SSE4.1, SSE4
Hi Alan,
Thanks so much for your promptly response. Based on your valuable input, I find
the following RN
http://www.c0t0d0s0.org/archives/4974-Whats-new-in-Solaris-10-1008-also-known-as-Update-6.html
and
x86: Kernel Support for Intel SSSE3, SSE4.1, SSE4.2, and AMD SSE4A
Am I finding the correc
On 04/ 4/16 05:56 PM, Yike Zhang wrote:
Hello there,
May I know if anyone hit the similar issue and guide me how to work around it?
Double check and found that AV_386_SSSE3 is not defined in the solaris10-u2
header file,
According to our bug tracker, it was added in Solaris 10 Update 6 (Solar
Hello there,
May I know if anyone hit the similar issue and guide me how to work around it?
I am trying to build and pixman library for Solaris10, but get the following
error
2016-03-30 18:15:32 gobuilds.Compile : 18:15:32.994 make INFO
CC pixman-x86.lo
2016-03-30 18:15:33
I believe there may have been a rebasing error. Will look into it.
I certainly intended this to change behavior when the filter size is odd,
not when the number of subsamples is odd. Not sure if this is truly rebase
screwing up, or I just mistyped an attempt to fix a rebase error.
On Mon, Apr 4,
No, it changes behavior when the number of *phases* is odd, which it is in
the example I gave.
Søren
On Mon, Apr 4, 2016 at 2:51 PM, Bill Spitzak wrote:
> That's why this only changes the behavior when the number of samples is
> odd.
>
>
> On Sun, Apr 3, 2016 at 11:17 AM, Søren Sandmann
> wro
On Sat, 02 Apr 2016 13:30:58 +0100, Mizuki Asakura wrote:
This patch only contains STD_FAST_PATH codes, not scaling (nearest,
bilinear) codes.
Hi Mizuki,
It looks like you have used an automated process to convert the AArch32
NEON code to AArch64. Will you be able to repeat that process for o
Okay that sounds pretty good. Also 'r' is better than 'i' since 'i' can be
mis-read as "input" or "image". 'r' I think is mostly going to be read as
"reverse" which actually makes sense.
Sorry to be a pain about this but I really find it confusing to use the
same term for different numbers.
On Su
That's why this only changes the behavior when the number of samples is odd.
On Sun, Apr 3, 2016 at 11:17 AM, Søren Sandmann
wrote:
> I don't believe this patch is correct.
>
> As an example, consider an image with an identity transformation and a
> cubic filter (which has width 4) with subsamp
> But it is much more interesting to compare the performance of this
> patch with the existing 32-bit ARM NEON code. You can build the
> 32-bit tests programs (including lowlevel-blt-bench) using a 32-bit
> ARM crosscompiler either on your desktop PC or on the ARM board:
>
> ./configure --host=ar
> OK, thanks for this information. What I mean is that this should be
> preferably a separate patch.
I've sent it on the separated patch.
On 3 April 2016 at 20:22, Siarhei Siamashka wrote:
> On Sat, 2 Apr 2016 20:28:44 +0900
> Mizuki Asakura wrote:
>
>> Thanks for your reply.
>>
>> > The main c
stride con be negative, but byte-stride is declared as uint32_t.
It may cause integer overflow.
Signed-off-by: Mizuki Asakura
---
pixman/pixman-arm-neon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pixman/pixman-arm-neon.c b/pixman/pixman-arm-neon.c
index be761c9..fcb61b
13 matches
Mail list logo
