Selon Nathan Ingersoll <[EMAIL PROTECTED]>:
> > > I recently got a G4 IBook and wanted to test evas on it; after some
> compiling
> > > problems, I get it to run and ... well, that's not bad but I was once
> more
> > > disapointed by its result (the 800MHz G4 that's in this computer doesn't
> seem
> > > to be very powerfull, be warned...). Well, the OpenGL version of the
evas
> test
> > >
> > > program run far better (thanks to the radeon 9200), but I wanted for
long
> to
> > > study a bit the altivec instruction set; I had found my guinea-pig.
> > > So, inspired by the mmx functions, I began to code some functions using
> > > altivec, while learning thanks to the Apple's tutorials. I first looked
> at the
> > >
> > > top 5 that gave me gprof on the evas_software_x11_test, and I got quite
> good
> > > results for me, to give just a few: a 60% gain in blending pixels on
> pixels,
> > > and 33% gain in copying pixels (I also made an altivec optimized version
> for
> > > blending colors and colors with alpha). For now they're not perfect, and
>
> > > surely need some corrections and enhancement, but I think I could soon
> send
> > > them to this list...
> > > I've got one little thing to say about blending, as the the precision
> concern
> > > was discussed on this list (about the division by 255): the mmx version
> > > doesn't give at all the same result as the C one ("not at all" doesn't
> mean
> > > they're totally different, but lots of results are off by 1), and
neither
> does
> > > my altivec version.
>
> Awesome! This takes one item off my TODO list. I did a YUV->RGB
> colorspace conversion routine a while back and intended to do the
> alpha-blending code next.
>
As I said in my previous email, the code I did isn't very clean cause I looked
at the mmx one and tried some "close" altivec instructions. So this part isn't
finished yet...
> If you've got some issues to iron out with it still, feel free to send
> it my way and I'll do what I can to lend a hand.
>
That's cool :) For now I'm cleaning up the patch, by putting #ifdef's where
it's needed, and I'll send it to you when it's done.
> > > The first problem is the memory consumption: I know that evas doesn't
> leak
> > > memory, I tested every Apple's tool to look at memory leaks, and I
didn't
> find
> > >
> > > anythink, but the evas test app is *filling up all the memory* !!! Not
> even
>
> Depending on which version of MacOSX you're using, there is a utility
> called Shark (built in to XCode now IIRC) that is quite useful for
> identifying hot spots in your code. There is also MallocDebug which is
> quite nice for monitoring memory use. It might be useful to give it a
> run through those.
>
I already tried MallocDebug, but it gave me nothing (I'm using MacOSX 10.3).
I'll look at shark. But it seems to be a strange problem that doesn't come
from evas. Did you get this bug ?
> As for the pseudo-C, there is a lib on Linux to provide the same
> functionality. You have to #include <altivec.h> and link to -laltivec,
> but it's supposed to be fairly compatible. That being said, I have not
> tested the current altivec optimizations on Linux yet. I think we need
> to add a couple configure checks for this to work. My hardware running
> Linux is too old and would not benefit from altivec.
>
Anyway, Apple's library isn't very attractive when you're willing to have very
fine-tuned optimizations.
And yes the configure would have to be updated (but well, if nobody can test
it ...)
> > > graphic intensive, at least for the first part, and maybe that's why X
> drawing
> > >
> > > routines come first, but this may be a problem when the others will be
> solved.
> >
> > basically x uses up about 15-20% of the display pipeline with doing copies
> from
> > client memory to the framebuffer. that is about the fastest i have managed
> to
> > get it. thats how it is on native x86 and native xservers.
> >
> > > If someone has a linux ppc comp to test this on, and could tell me if
> these
> > > problems arise on a native X display, it would be great (I plan to
> install
> > > linux one day on mine, but for now it's quite in early stage of
> developement,
> > > even if it already works on most of the recent G4s).
>
> FYI, I saw a tremendous drop in performance under OS X at one point
> about a year ago. After upgrading X, my evas test dropped from somewhere
> around 1.0 down to around 0.500. I think fink may install some X libs
> that are not optimal for the Apple X server.
>
I use the X server from apple, even if I got evas' necessary libs from fink.
And as I only got my mac for 4 months now, so I can't compare ... I got
(before optimizations) about 40 fps in the evas test (don't remember the
score), but I wasn't aware of the memory problem (which slows things down a
lot), and now (after optimizations and leaving only the evas test to keep a
maximum of free memory) i get around (but below) 60 fps .... but it depends
...
> Good luck!
Thanks, you too !
> Nathan
>
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
