Enlightenment

Hello Ben,

	Good to see someone finally testing this.  Obviously works
for me, but that doesn't count ;-)

On Sat, 22 May 2010 23:46:56 +0200
Benjamin Zores <ben@...> wrote:

> Hi,
> 
> I'm no longer able to build evas on ARM Cortex-A8 (using NEON
> optimizations) after r48733
> (see http://trac.enlightenment.org/e/changeset/48733 the one with NEON
> optimizations actually).
> 
> Below is GCC output:
> 
> ben@...$
> /home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/bin/armv7-geexbox-linux-gnueabi-gcc
<SNIP>
> In file included from evas_op_blend_main_.c:92:
> ./evas_op_blend/op_blend_mask_color_neon.c: In function
> '_op_blend_mas_c_dp_neon':
> ./evas_op_blend/op_blend_mask_color_neon.c:8: warning: unused
> variable 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:7:
> warning: unused variable
> 'e' ./evas_op_blend/op_blend_mask_color_neon.c: In function
> '_op_blend_mas_can_dp_neon': ./evas_op_blend/op_blend_mask_color_neon.c:169:
> warning: unused variable
> 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:168: warning:
> unused variable 'tmp' /tmp/cccYHaUV.s: Assembler
> messages: /tmp/cccYHaUV.s:8166: Error: invalid neon suffix for non
> neon instruction /tmp/cccYHaUV.s:8304: Error: invalid neon suffix for
> non neon instruction
> 
> Attached is the bzip'ed generated assembly file.

Attachment didn't come through.  Try the change below first, otherwise
can you either put it on the web somewhere or mail it to me?  Else just
paste 5 lines around 8166 & 8304.

A first guess however:
	There are two ldr.32 instructions, which may be the issue.
	The .32 is redundant, so try changing them to ldr.
The lines are:
 	72 & 235 of op_blend_mask_color_neon.c

> Evas is cross-compiled using:
> - GCC 4.4.4
> - Binutils 2.20.51.0.8
> - eGlibc 2.11
> 
> Any idea how to fix this bug ? Any special CFLAGS to be added maybe
> (though it used to compile just fine before) ?

The flags in the commit message are needed:
	-mfloat-abi=softfp -mfpu=neon
Also make sure you set the appropriate CPU[1]
	-mcpu=cortex-a8

The build have been tested on gcc 4.4.1 from code sourcery before.

	Regards,
	nash


[1] And if anyone wants to tell me to use -march -mtune etc... go away.

On Sat, 22 May 2010 23:46:56 +0200 Benjamin Zores <ben@...> said:

any reason you use just -O not -O2?

fyi - no attached file - sf.net filtered it out. :) though generally this kind
of a problem is a result of compiler issues - eg no neon support in gcc (or
poor/older support) etc. generally anyway.

> Hi,
> 
> I'm no longer able to build evas on ARM Cortex-A8 (using NEON
> optimizations) after r48733
> (see http://trac.enlightenment.org/e/changeset/48733 the one with NEON
> optimizations actually).
> 
> Below is GCC output:
> 
> ben@...
> $ /home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/bin/armv7-geexbox-linux-gnueabi-gcc
> -DHAVE_CONFIG_H -I. -I../../../.. -I. -I../../../../src/lib
> -I../../../../src/lib/cserve -I../../../../src/lib/include
> -DPACKAGE_BIN_DIR=
> \"/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/bin
> \" -DPACKAGE_LIB_DIR=
> \"/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/lib
> \" -DPACKAGE_DATA_DIR=
> \"/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/share/evas
> \"
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/freetype2
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/eina-0
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/eina-0/eina
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/eina-0
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/eina-0/eina
> -I/home/ben/GeeXboX/geexbox/build.arm.eglibc/toolchain/armv7-geexbox-linux-gnueabi/sysroot/usr/local/include/fribidi
> -O -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -mtune=cortex-a8 -Wall
> -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fPIC -s -fomit-frame-pointer
> -D_GNU_SOURCE -MT evas_op_blend_main_.lo -MD -MP
> -MF .deps/evas_op_blend_main_.Tpo -c evas_op_blend_main_.c  -fPIC -DPIC
> -o .libs/evas_op_blend_main_.o In file included from
> evas_op_blend_main_.c:92: ./evas_op_blend/op_blend_mask_color_neon.c: In
> function
> '_op_blend_mas_c_dp_neon': ./evas_op_blend/op_blend_mask_color_neon.c:8:
> warning: unused variable
> 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:7: warning: unused
> variable 'e' ./evas_op_blend/op_blend_mask_color_neon.c: In function
> '_op_blend_mas_can_dp_neon': ./evas_op_blend/op_blend_mask_color_neon.c:169:
> warning: unused variable
> 'alpha' ./evas_op_blend/op_blend_mask_color_neon.c:168: warning: unused
> variable 'tmp' /tmp/cccYHaUV.s: Assembler messages: /tmp/cccYHaUV.s:8166:
> Error: invalid neon suffix for non neon instruction /tmp/cccYHaUV.s:8304:
> Error: invalid neon suffix for non neon instruction
> 
> Attached is the bzip'ed generated assembly file.
> 
> Evas is cross-compiled using:
> - GCC 4.4.4
> - Binutils 2.20.51.0.8
> - eGlibc 2.11
> 
> Any idea how to fix this bug ? Any special CFLAGS to be added maybe
> (though it used to compile just fine before) ?
> 
> Ben
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Sun, May 23, 2010 at 5:03 AM, Brett Nash <nash@...> wrote:
> Hello Ben,
>
>        Good to see someone finally testing this.  Obviously works
> for me, but that doesn't count ;-)

Sure :p

> Attachment didn't come through.  Try the change below first, otherwise
> can you either put it on the web somewhere or mail it to me?  Else just
> paste 5 lines around 8166 & 8304.
>
> A first guess however:
>        There are two ldr.32 instructions, which may be the issue.
>        The .32 is redundant, so try changing them to ldr.
> The lines are:
>        72 & 235 of op_blend_mask_color_neon.c

One can say you know your good damn well :p
This was indeed the issue, without having to see the generated assembly.
Attached (hopefully this time) is "your" patch.

> The flags in the commit message are needed:
>        -mfloat-abi=softfp -mfpu=neon
> Also make sure you set the appropriate CPU[1]
>        -mcpu=cortex-a8

They obviously were used :-)

Thx,

Ben

On Sun, May 23, 2010 at 6:22 AM, Carsten Haitzler <raster@...> wrote:
> On Sat, 22 May 2010 23:46:56 +0200 Benjamin Zores <ben@...> said:
>
> any reason you use just -O not -O2?
>
> fyi - no attached file - sf.net filtered it out. :) though generally this kind
> of a problem is a result of compiler issues - eg no neon support in gcc (or
> poor/older support) etc. generally anyway.

It used to be -O4 actually. Then I just switch to -O just to ensure it
was not triggered by any compiler optimization bug.
Apparently this wasn't the case.

Ben

On Sun, 23 May 2010 11:05:12 +0200
Benjamin Zores <ben@...> wrote:

> On Sun, May 23, 2010 at 5:03 AM, Brett Nash <nash@...> wrote:
> > Hello Ben,
> >
> >        Good to see someone finally testing this.  Obviously works
> > for me, but that doesn't count ;-)
> 
> Sure :p
> 
> > Attachment didn't come through.  Try the change below first,
> > otherwise can you either put it on the web somewhere or mail it to
> > me?  Else just paste 5 lines around 8166 & 8304.
> >
> > A first guess however:
> >        There are two ldr.32 instructions, which may be the issue.
> >        The .32 is redundant, so try changing them to ldr.
> > The lines are:
> >        72 & 235 of op_blend_mask_color_neon.c
> 
> One can say you know your good damn well :p
> This was indeed the issue, without having to see the generated
> assembly. Attached (hopefully this time) is "your" patch.

I'll apply tomorrow morning.
The error was quasi-obvious from the compiler message.  I'm curious as
to why code sourcery's gcc lets it pass without comment however.

If you have time, I'd love to see any benchmarks you can generate ;-)

	Regards,
	nash

On Sun, May 23, 2010 at 11:25 AM, Brett Nash <nash@...> wrote:

> If you have time, I'd love to see any benchmarks you can generate ;-)

That is planned as soon as the whole distro is functionnal and when I
manage to get my hands on the board.
I could however have some tests on N900 but this will involve much more work.
I'll let you know ASAP anyhow (probably a 2 weeks).

Ben

On Sun, 23 May 2010 11:06:24 +0200 Benjamin Zores <ben@...> said:

> On Sun, May 23, 2010 at 6:22 AM, Carsten Haitzler <raster@...>
> wrote:
> > On Sat, 22 May 2010 23:46:56 +0200 Benjamin Zores <ben@...> said:
> >
> > any reason you use just -O not -O2?
> >
> > fyi - no attached file - sf.net filtered it out. :) though generally this
> > kind of a problem is a result of compiler issues - eg no neon support in
> > gcc (or poor/older support) etc. generally anyway.
> 
> It used to be -O4 actually. Then I just switch to -O just to ensure it
> was not triggered by any compiler optimization bug.
> Apparently this wasn't the case.

aaah gotcha. tho in my experience -O2 is about as good as it gets without using
-mtune/cpu etc to generate instructions for a specific architecture level or
tune for it. at least in my experience. i have a suggestion. dont go about -O2
unless you can really justify it - that means benchmarks show real solid
speedups (consistently more than 5%). in the past at least -O3 and above have
also been wonderful sources of compiler bugs, that produce incorrect code - and
you may end up suffering from bugs that don't actually exist in the code - but
lie in the compiler, so... just beware of high -O levels. test to be sure it
actually is worth it. do real benchmarking. remember it's a risk tradeoff - you
gain N% more speed for a higher chance of bugs (that cant actually be fixed in
the src - but in the compiler which makes it harder). thus why i say more than
5% - it is, of course, a fuzzy number, but it means "you need a real
significant and noticeable speedup".

for evas at any rate, use expedite and do benchmarks. better results come from
higher -c counts (loop count - so the more loops it does the less you'll be hit
by entropy - default is 128 - so use -c 256 if you are patient if you want very
accurate results). as an example - results for x86 (32bit) evas speed
(weighted):

-O0 185.74
-O1 271.33
-O2 274.52
-O3 274.30
-O4 272.46

(all of them used -march=nocona as well in CFLAGS - on a core2 duo laptop).

notice performance actually peaks at -O2 :) (also -O0 is horrible - but just to
note - i write a lot of my code to assume a compiler will have a decent
optimiser, so it will pick up the pieces with what may seem "stupid code", but
that "sutpid code" is meant to be more readable/maintainable

(need i get into -funroll-loops ?) :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

SVN-ised.  Also removed the commented out vldr instruction as well.

	Thanks again,
	Regards,
	nash

On Sun, 23 May 2010 11:05:12 +0200
Benjamin Zores <ben@...> wrote:

> On Sun, May 23, 2010 at 5:03 AM, Brett Nash <nash@...> wrote:
> > Hello Ben,
> >
> >        Good to see someone finally testing this.  Obviously works
> > for me, but that doesn't count ;-)
> 
> Sure :p
> 
> > Attachment didn't come through.  Try the change below first,
> > otherwise can you either put it on the web somewhere or mail it to
> > me?  Else just paste 5 lines around 8166 & 8304.
> >
> > A first guess however:
> >        There are two ldr.32 instructions, which may be the issue.
> >        The .32 is redundant, so try changing them to ldr.
> > The lines are:
> >        72 & 235 of op_blend_mask_color_neon.c
> 
> One can say you know your good damn well :p
> This was indeed the issue, without having to see the generated
> assembly. Attached (hopefully this time) is "your" patch.
> 
> > The flags in the commit message are needed:
> >        -mfloat-abi=softfp -mfpu=neon
> > Also make sure you set the appropriate CPU[1]
> >        -mcpu=cortex-a8
> 
> They obviously were used :-)
> 
> Thx,
> 
> Ben

On Sun, May 23, 2010 at 11:33 AM, Brett Nash <nash@...> wrote:
> On Sun, 23 May 2010 11:28:45 +0200
> Benjamin Zores <ben@...> wrote:
>
>> On Sun, May 23, 2010 at 11:25 AM, Brett Nash <nash@...> wrote:
>>
>> > If you have time, I'd love to see any benchmarks you can
>> > generate ;-)
>>
>> That is planned as soon as the whole distro is functionnal and when I
>> manage to get my hands on the board.
>> I could however have some tests on N900 but this will involve much
>> more work. I'll let you know ASAP anyhow (probably a 2 weeks).
>
> 2 weeks is fine ;-)  Looking forward to it ;-)

Took me a bit less than 2 weeks actually.
So I managed to run Expedite on my board and seems to have pretty
decent results.

Attached is a copy of the benchmark scores.
I only did it using software_x11 renderer right now as I still have
issues with GLES renderer (distro/driver issue, not Evas related).

So, the board is an OMAP3 ARMv7 Cortex-A8 SoC clocked at 720 MHz (IGEPv2 board).
I've been running in 720p with a 32bits framebuffer on Linux 2.6.33.5.
X.Org 1.7.5 is used without composite nor any window/desktop manager
and is running with omapfb_xorg driver.
The system nearly has no processes running (except vital/mandatory
ones) - GeeXboX OS.
All EFLs (including expedite) have been cross-compiled using GCC 4.4.4
with -O4 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp.
ELFs are based on r49141, so including the latest ARM NEON optimizations.

The final Evas score is:
170.88 , EVAS SPEED (WEIGHTED)

FYI, I used to ran Expedite (older EFL revision, without latest ARM
optimizations) on OMAP3 TouchBook,
using OpenEmbedded derivated distro, with GLES on Xorg/fbdev driver
(slow as hell) and score used to be around 13 only !!
I remember N900 test results to be higher than what I measured on
Touchbook (but my own tests were much lower than Raster's ones)
but definitely not as high as a 171 score.

So it definitely seems like a very good improvement.

Full details in attachment.

Ben

-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama

On Wed, 2 Jun 2010 00:31:49 +0200 Benjamin Zores <ben@...> said:

> On Sun, May 23, 2010 at 11:33 AM, Brett Nash <nash@...> wrote:
> > On Sun, 23 May 2010 11:28:45 +0200
> > Benjamin Zores <ben@...> wrote:
> >
> >> On Sun, May 23, 2010 at 11:25 AM, Brett Nash <nash@...> wrote:
> >>
> >> > If you have time, I'd love to see any benchmarks you can
> >> > generate ;-)
> >>
> >> That is planned as soon as the whole distro is functionnal and when I
> >> manage to get my hands on the board.
> >> I could however have some tests on N900 but this will involve much
> >> more work. I'll let you know ASAP anyhow (probably a 2 weeks).
> >
> > 2 weeks is fine ;-)  Looking forward to it ;-)
> 
> Took me a bit less than 2 weeks actually.
> So I managed to run Expedite on my board and seems to have pretty
> decent results.
> 
> Attached is a copy of the benchmark scores.
> I only did it using software_x11 renderer right now as I still have
> issues with GLES renderer (distro/driver issue, not Evas related).
> 
> So, the board is an OMAP3 ARMv7 Cortex-A8 SoC clocked at 720 MHz (IGEPv2
> board). I've been running in 720p with a 32bits framebuffer on Linux 2.6.33.5.
> X.Org 1.7.5 is used without composite nor any window/desktop manager
> and is running with omapfb_xorg driver.
> The system nearly has no processes running (except vital/mandatory
> ones) - GeeXboX OS.
> All EFLs (including expedite) have been cross-compiled using GCC 4.4.4
> with -O4 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp.
> ELFs are based on r49141, so including the latest ARM NEON optimizations.
> 
> The final Evas score is:
> 170.88 , EVAS SPEED (WEIGHTED)
> 
> FYI, I used to ran Expedite (older EFL revision, without latest ARM
> optimizations) on OMAP3 TouchBook,
> using OpenEmbedded derivated distro, with GLES on Xorg/fbdev driver
> (slow as hell) and score used to be around 13 only !!
> I remember N900 test results to be higher than what I measured on
> Touchbook (but my own tests were much lower than Raster's ones)
> but definitely not as high as a 171 score.
> 
> So it definitely seems like a very good improvement.
> 
> Full details in attachment.
> 
> Ben

you need to take current evas and run on the other platforms. why? we now weigh
results based on a finger-in-the-wind guess at real-life usage. so some tests
get a low multiplier, some high in the weighting to produce the final result,
BUT... you have a problem. the textblock intl result has rediculous results.
you need to watch it render - and my bet is that its not rendering anything
there - it's blank. you're missing fonts for other languages (japanese,
chinese, korean, arabic, etc. etc.). you cannot really use those results there
as one of your tests is actually broken and as a result is tweaking the final
number to be totally unrealistic. generally the right thing to do is to compare
2 runs of the same version of expedite (well at least so they both do the
weighting and have the same tests) and test-by-test look at it and the relative
results per test and take a guess if that particular rendering/display is used
much in your apps/usage etc. if not- ignore it.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Wed, 2 Jun 2010 00:31:49 +0200
Benjamin Zores <ben@...> wrote:
> Took me a bit less than 2 weeks actually.
> So I managed to run Expedite on my board and seems to have pretty
> decent results.

Actually they look pretty average to me. :-/ But I'd really need to see
your baseline.

Can you just rebuild evas _without_ neon enabled (you only need to
recompile evas, doesn't effect any other library).

Most of the times are _slower_ the speeds I got without neon.
I'm testing I'm a board which is slightly faster clock speed, but
otherwise seems to be similar.

Looking at the results there seems to be a problem with your font
rendering.  First is the textblock one, which is out of this world.
Second your text ones seem to be otherwise quite slow.  My image based
tests are 50-100% quicker, but the text ones are 200%+ or faster.  Most
strange.

Looking at the ratios to my tests, my feeling is neon isn't working I
have to say.

> Attached is a copy of the benchmark scores.
> I only did it using software_x11 renderer right now as I still have
> issues with GLES renderer (distro/driver issue, not Evas related).
> 
> So, the board is an OMAP3 ARMv7 Cortex-A8 SoC clocked at 720 MHz
> (IGEPv2 board). I've been running in 720p with a 32bits framebuffer
> on Linux 2.6.33.5. X.Org 1.7.5 is used without composite nor any
> window/desktop manager and is running with omapfb_xorg driver.
> The system nearly has no processes running (except vital/mandatory
> ones) - GeeXboX OS.
> All EFLs (including expedite) have been cross-compiled using GCC 4.4.4
> with -O4 -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp.

Try -O2.  Arms don't have great caches.  I found -O3 slower then -O2.
(never tried -O4).  -Os is also noticeably slower then O2.


> ELFs are based on r49141, so including the latest ARM NEON
> optimizations.
> 
> The final Evas score is:
> 170.88 , EVAS SPEED (WEIGHTED)
> 
> FYI, I used to ran Expedite (older EFL revision, without latest ARM
> optimizations) on OMAP3 TouchBook,
> using OpenEmbedded derivated distro, with GLES on Xorg/fbdev driver
> (slow as hell) and score used to be around 13 only !!

You textblock intl will be rather heavily changing that number.  I have
a number in the order of 50 for my score, and most of my tests are
quicker.

Best bet is to run expedite with and without a evas with neon, and dump
the results in a spreadsheet (or use the comparison program).

> I remember N900 test results to be higher than what I measured on
> Touchbook (but my own tests were much lower than Raster's ones)
> but definitely not as high as a 171 score.
> 
> So it definitely seems like a very good improvement.

If only it was that good ;-)

	Regards,
	nash

On Wed, Jun 2, 2010 at 5:58 AM, Brett Nash <nash@...> wrote:

> Can you just rebuild evas _without_ neon enabled (you only need to
> recompile evas, doesn't effect any other library).

> Looking at the ratios to my tests, my feeling is neon isn't working I
> have to say.

How could that be ?
If it's compiled in, it's getting use, right ?
Or is there some env var to be set as for async rendering ?

> Try -O2.  Arms don't have great caches.  I found -O3 slower then -O2.
> (never tried -O4).  -Os is also noticeably slower then O2.

Will try.

> You textblock intl will be rather heavily changing that number.  I have
> a number in the order of 50 for my score, and most of my tests are
> quicker.

No idea why, but will check.

> If only it was that good ;-)

Yeah well, the scores are better than the one I experienced on N900.
FYI, I've tried expedite on N900 months ago, either with my or Raster
pre-built EFLs and I had results 5x slower than the one on raster's
website.

Ben


-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama

On Wed, 2 Jun 2010 09:08:56 +0200 Benjamin Zores <ben@...> said:

> On Wed, Jun 2, 2010 at 5:58 AM, Brett Nash <nash@...> wrote:
> 
> > Can you just rebuild evas _without_ neon enabled (you only need to
> > recompile evas, doesn't effect any other library).
> 
> > Looking at the ratios to my tests, my feeling is neon isn't working I
> > have to say.
> 
> How could that be ?
> If it's compiled in, it's getting use, right ?
> Or is there some env var to be set as for async rendering ?

async != neon. neon requires a --enable. async rendering wont help you unless
you have more than 1 core. and yes - it needs an env var set. its in the README.

> > Try -O2.  Arms don't have great caches.  I found -O3 slower then -O2.
> > (never tried -O4).  -Os is also noticeably slower then O2.
> 
> Will try.
> 
> > You textblock intl will be rather heavily changing that number.  I have
> > a number in the order of 50 for my score, and most of my tests are
> > quicker.
> 
> No idea why, but will check.
> 
> > If only it was that good ;-)
> 
> Yeah well, the scores are better than the one I experienced on N900.
> FYI, I've tried expedite on N900 months ago, either with my or Raster
> pre-built EFLs and I had results 5x slower than the one on raster's
> website.

unless you run expedite fullscreen, the n900 also runs a compositor - and that
massively hits performance numbers. it's not a very optimal gl/compositing path
on the n900's drivers.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Wed, 2 Jun 2010 09:08:56 +0200
Benjamin Zores <ben@...> wrote:

> On Wed, Jun 2, 2010 at 5:58 AM, Brett Nash <nash@...> wrote:
> 
> > Can you just rebuild evas _without_ neon enabled (you only need to
> > recompile evas, doesn't effect any other library).
> 
> > Looking at the ratios to my tests, my feeling is neon isn't working
> > I have to say.
> 
> How could that be ?
> If it's compiled in, it's getting use, right ?

There is the --enable-cpu-neon arg to configure, and a run time check.
As long as they both pass, it will use neon.

If you really want to check open one of the _neon files in blend, shove
a printf there and make sure it gets printed (then get rid of it
because your performance will then suck ;-)

> > If only it was that good ;-)
> 
> Yeah well, the scores are better than the one I experienced on N900.
> FYI, I've tried expedite on N900 months ago, either with my or Raster
> pre-built EFLs and I had results 5x slower than the one on raster's
> website.

As raster said: Head expedite uses a weighted average.

I think it was mostly to make sure neon doesn't look too good on the
massive speed ups in image blending tests ;-)

	Regards,
	nash

On Wed, Jun 2, 2010 at 9:23 AM, Carsten Haitzler <raster@...> wrote:

> async != neon. neon requires a --enable. async rendering wont help you unless
> you have more than 1 core. and yes - it needs an env var set. its in the README.

Yeah I'm fully aware of that.
Though, as I used the enable-neon flag, that configures confirmed that
and that *_neon.c files gets compiled in, I can't see a reason why it
wouldn't be used, as pointed by Brett.

Ben

On Wed, 2 Jun 2010 09:39:30 +0200
Benjamin Zores <ben@...> wrote:

> On Wed, Jun 2, 2010 at 9:23 AM, Carsten Haitzler
> <raster@...> wrote:
> 
> > async != neon. neon requires a --enable. async rendering wont help
> > you unless you have more than 1 core. and yes - it needs an env var
> > set. its in the README.
> 
> Yeah I'm fully aware of that.
> Though, as I used the enable-neon flag, that configures confirmed that
> and that *_neon.c files gets compiled in, I can't see a reason why it
> wouldn't be used, as pointed by Brett.

Can you rebuild with it disabled, and try against the non-neonized evas?

I just was expecting some better numbers... but without a baseline they
are bit meaningless.

	Regards,
	nash

On Wed, 2 Jun 2010 16:35:32 +0800 Brett Nash <nash@...> said:

> On Wed, 2 Jun 2010 09:39:30 +0200
> Benjamin Zores <ben@...> wrote:
> 
> > On Wed, Jun 2, 2010 at 9:23 AM, Carsten Haitzler
> > <raster@...> wrote:
> > 
> > > async != neon. neon requires a --enable. async rendering wont help
> > > you unless you have more than 1 core. and yes - it needs an env var
> > > set. its in the README.
> > 
> > Yeah I'm fully aware of that.
> > Though, as I used the enable-neon flag, that configures confirmed that
> > and that *_neon.c files gets compiled in, I can't see a reason why it
> > wouldn't be used, as pointed by Brett.
> 
> Can you rebuild with it disabled, and try against the non-neonized evas?
> 
> I just was expecting some better numbers... but without a baseline they
> are bit meaningless.

the soc you have has a much better memory subsystem/ram from what i gather - so
clockrate isn't the real factor here thats making the difference between the 2
soc's


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Wed, Jun 2, 2010 at 10:35 AM, Brett Nash <nash@...> wrote:

> Can you rebuild with it disabled, and try against the non-neonized evas?
>
> I just was expecting some better numbers... but without a baseline they
> are bit meaningless.

Yes, that's planned for tonight.

Ben


-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama

On Wed, Jun 2, 2010 at 10:45 AM, Benjamin Zores <ben@...> wrote:
> On Wed, Jun 2, 2010 at 10:35 AM, Brett Nash <nash@...> wrote:
>
>> Can you rebuild with it disabled, and try against the non-neonized evas?
>>
>> I just was expecting some better numbers... but without a baseline they
>> are bit meaningless.
>
> Yes, that's planned for tonight.

So here are the new benchs.
Same board, IGEPv2 @ 720 MHz, using software_x11, without (left) and
with (right) NEON optimizations.

Regarding "Textblock Intl", there used to be an issue because of
Expedite not using right datadir when cross-compiled
that I fixed (and all PNGs, TTFs, fonts.dir and fonts.alias files are
present at the right place according to strace)
but the too-big-to-be-true score remains.

Anyhow, NEON optimizations add a 30.2% boost.
See http://geexbox.org/~ben/expedite-neon-omap3-igepv2.html

For other tests, can you share the value you reached on other OMAP boards ?

Ben

-- 
"My life, and by extension everyone else's is meaningless."
Bender, Futurama

On Wed, 2 Jun 2010 22:01:43 +0200 Benjamin Zores <ben@...> said:

> On Wed, Jun 2, 2010 at 10:45 AM, Benjamin Zores <ben@...> wrote:
> > On Wed, Jun 2, 2010 at 10:35 AM, Brett Nash <nash@...> wrote:
> >
> >> Can you rebuild with it disabled, and try against the non-neonized evas?
> >>
> >> I just was expecting some better numbers... but without a baseline they
> >> are bit meaningless.
> >
> > Yes, that's planned for tonight.
> 
> So here are the new benchs.
> Same board, IGEPv2 @ 720 MHz, using software_x11, without (left) and
> with (right) NEON optimizations.
> 
> Regarding "Textblock Intl", there used to be an issue because of
> Expedite not using right datadir when cross-compiled
> that I fixed (and all PNGs, TTFs, fonts.dir and fonts.alias files are
> present at the right place according to strace)
> but the too-big-to-be-true score remains.
> 
> Anyhow, NEON optimizations add a 30.2% boost.
> See http://geexbox.org/~ben/expedite-neon-omap3-igepv2.html
> 
> For other tests, can you share the value you reached on other OMAP boards ?

can't right now - only thing i can test on is my n900 and the nokia sdk i had
set up vanished recently with some packing up and getting rid of things. so
can't give recent numbers.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Wed, 2 Jun 2010 22:01:43 +0200
Benjamin Zores <ben@...> wrote:

> On Wed, Jun 2, 2010 at 10:45 AM, Benjamin Zores <ben@...>
> wrote:
> > On Wed, Jun 2, 2010 at 10:35 AM, Brett Nash <nash@...> wrote:
> >
> >> Can you rebuild with it disabled, and try against the non-neonized
> >> evas?
> >>
> >> I just was expecting some better numbers... but without a baseline
> >> they are bit meaningless.
> >
> > Yes, that's planned for tonight.
> 
> So here are the new benchs.
> Same board, IGEPv2 @ 720 MHz, using software_x11, without (left) and
> with (right) NEON optimizations.

Those numbers look about right, and similar improvements to what I
have.

A couple of regressions I don't have: Not using the gcc args to allow
neon slows gcc down by about 1-3%, so neon generally claws that back
with substantial interest.

> Regarding "Textblock Intl", there used to be an issue because of
> Expedite not using right datadir when cross-compiled
> that I fixed (and all PNGs, TTFs, fonts.dir and fonts.alias files are
> present at the right place according to strace)
> but the too-big-to-be-true score remains.

Good to see neon improved "crazy performance" to "absolutely absurd
performance" ;-)

> Anyhow, NEON optimizations add a 30.2% boost.
> See http://geexbox.org/~ben/expedite-neon-omap3-igepv2.html

Thanks for that.

	Regards,
	nash