On Tue, Jul 14, 2015 at 11:48 AM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Thu, 2 Jul 2015 13:04:17 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
no changes were observed when running cairo trimmed benchmarks.
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
This shows
On Tue, 14 Jul 2015 15:48:54 +0200
Thomas Petazzoni thomas.petazz...@free-electrons.com wrote:
Hello,
On Tue, 14 Jul 2015 15:34:30 +0300, Pekka Paalanen wrote:
There is one more bit of automation: when a commit gets pushed into the
upstream git repository, a git hook will run that
On Wed, 2015-07-15 at 16:36 +0300, Oded Gabbay wrote:
+else
+{
+ return FALSE;
+}
+
+vfiller = create_mask_1x32_128(filler);
This appears to be less of a regression for small operations if you
fall back to the C code for byte_width 64 here. That seems to be
about the
On Tue, Jul 14, 2015 at 11:40 AM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Just one question about the code. There are some places where both big
and little endian variants are identical but we still have an ifdef:
+static
On Wed, Jul 15, 2015 at 2:59 PM, Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 14 Jul 2015 11:41:25 +0300
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
On Thu, 2 Jul 2015 13:04:11 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le.
On Tue, Jul 14, 2015 at 11:41 AM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
It is a good idea to have at least one benchmark result in the commit
message. Or provide a convincing explanation why this particular code
is beneficial. The no changes were observed commit message does not
On Tue, Jul 14, 2015 at 11:46 AM, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
On Thu, 2 Jul 2015 13:04:16 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
no changes were observed when running cairo trimmed benchmarks.
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
This seems to
On Tue, 14 Jul 2015 11:41:25 +0300
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
On Thu, 2 Jul 2015 13:04:11 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le.
reference memcpy speed = 24764.8MB/s (6191.2MP/s for 32bpp fills)
*Very*
On Wed, 15 Jul 2015 15:05:21 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
On Wed, Jul 15, 2015 at 2:59 PM, Pekka Paalanen ppaala...@gmail.com wrote:
On Tue, 14 Jul 2015 11:41:25 +0300
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
On Thu, 2 Jul 2015 13:04:11 +0300
Oded Gabbay
On Wed, Jul 15, 2015 at 4:06 PM, Pekka Paalanen ppaala...@gmail.com wrote:
On Wed, 15 Jul 2015 15:41:19 +0300
Oded Gabbay oded.gab...@gmail.com wrote:
Or if we don't care about that, why?
I think that the speedups in this specific patch are more substantial
than the slowdowns. If it was
It was benchmarked against commid id 2be523b from pixman/master
POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le.
cairo trimmed benchmarks :
Speedups
t-firefox-asteroids 533.92 - 489.94 : 1.09x
Signed-off-by: Oded Gabbay oded.gab...@gmail.com
Acked-by: Siarhei Siamashka
Based on sse2 impl.
It was benchmarked against commid id 2be523b from pixman/master
Tested cairo trimmed benchmarks on POWER8, 8 cores, 3.4GHz,
RHEL 7.1 ppc64le :
speedups
t-swfdec-giant-steps 1382.86 - 719.65 : 1.92x speedup
t-gnome-system-monitor 1405.45 - 923.71 :
It was benchmarked against commid id 2be523b from pixman/master
POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le.
reference memcpy speed = 24764.8MB/s (6191.2MP/s for 32bpp fills)
Before After Change
-
L1
13 matches
Mail list logo
