Selon Nathan Ingersoll <[EMAIL PROTECTED]>: > On Thu, Jun 10, 2004 at 05:19:20PM +0200, [EMAIL PROTECTED] wrote: > > I've been a bit late, but finally it's here ! > > I yesterday hit the 60 fps boundary, and I now get a score of at least 1.0 > in > > the evas demo's test ! (thanks to the memory i bought some weeks ago ... > yes, > > there's still the memory problem in evas on PPC). > > FYI, I saw a huge performance jump when I upgraded from 10.2 to 10.3. > Probably something to do with X11 libs.
When i got my ibook, it already had 10.3. I'm quite new to the mac world. > > OS X is a bit of a memory hog, 512 MB is about the minimum I would run > it with. Yes, i saw a big difference in speed for the system when i added memory. On this point, MacOSX make me think of WinXP ... > > When i apply this patch, i get an improvement of about 20-30% in speed. If > > > others could report theirs ... > > Following is a detailled description of what a did, sorry if it's a bit > > long... > > I removed the vec_dst/vec_dstst/vec_dss stuff from the code. Apple > claims that these can have a very detrimental affect on G5's and the > improvement on the G4 is usually negligible. Here are my numbers that > support that: Well, that's true that for G5 it isn't very effective, but for G4 it can be a big benefit sometimes. I didn't make any bench (just a few test, to see) on my machine, but i'll try to do some. Moreover, i didn't tune the size/count/ stride parameters to DST; maybe they're not at their best on your machine. And i'll add that, for the moment, G5 are quite marginals (i don't know anybody who own one) as they're quite expensive. And they're very powerfull, so leaving some instructions that "may" slow them isn't that important, i think. > > Problems: > > * I always get the big memory comsuption problem. Even if i now got an > > additionnal 512MB RAM upgrade, this is a big issue for "memory impaired" > > computers. > > I see this as well with evas_software_x11_test, it grows continuously > during the benchmark phase until it hits around 240 MB then it seems to > calm down, but not as many updates are happening either. I'll run it through > some leak detectors to see what I can find. Well, i already did that, and found nothing ! (see my previous messages) Maybe you'll be luckier ... But it's really a big problem when you don't have a lot of memory (when i had 256MB, it was hawfull) > > > * My patch doesn't correct general OSX problems, especially with the > > autotools. First, the configure stops on an error about directfb. I had to > > > remove the test (and susbtitue some flags given to gcc). Then, the > configure > > doesn't check for the libs (libpng and libjpeg) in the prefix given to it > > (generally if you use fink, it's in /sw). And then, even if the configure > says > > that altivec is enabled, the BUILD_ALTIVEC define isn't defined ... I had > to > > solve it by hand (modify the config.h ...). But i think that all come from > my > > version of the autotools (but this is the original version that most OSX > users > > will have ...). > > For the directfb issue, you need to install pkgconfig (available through > fink), > then it won't error out. The BUILD_ALTIVEC stuff in CVS has apparently > been broken since I last checked. I'll fix this and commit it with your > patch. OK, i'll install pkg_config (although i thought i installed it with gtk2 ...) to see if it works. > > > * The #ifdef in these drawing methods choice's functions are becoming a bit > > > messy ... Furthermore, they're organised differently all along the file. > Maybe > > it could be cleaned a bit. Especially, should we test for the processor > > capability (mmx, sse, altivec ...) when there's only one compiled in, and > no c > > fallback ? (what i don't do with altivec: if altivec is compiled in and not > C, > > processor's altivec capability isn't tested. Yes, this again add some > > ifdefs... and raise an "illegal instruction" exception on processors older > > > than G4... but, well, you had to compile your code correctly!). > > The CPU checks should work at runtime on older processors. I tested > it on a G3 and a 603e with correct detection and recovery. As far as the > ifdef's are concerned, I agree that they are getting a little unwieldy > in parts. If you are seeing illegal instruction crashes, let me know. The "illegal instruction" was just a though about how it would run on G3 or older processors. I only own a G4, so there is no problem ;-) But the ifdefs i put have to be corrected if we should keep detection at runtime. > > > * I removed some macros i first made some time ago, i left some in, and i > > don't know which is usefull or not... Anyway, there's always a common > altivec > > header to define typedef for vector type (that are otherwise very long to > type > > ...). And i left all the macros in the header, if someone is interested. > > I may move the evas_convert_yuv.c altivec routine over to those types, > though the naming scheme isn't quite consistent with how most parts of > evas are named. It is definitely much nicer to not have 30+ character > types. That's the Apple notation, and yes it isn't very consistent with evas naming scheme, but mmx macros aren't either. So ... > > > Remark: > > > > * I don't know what kind of indentation you use (i suspect emacs' one) but > it > > sounds wired to me... At least in vim, it's quite difficult to indent > > correctly everything... :-/ > > It's raster style, he uses jed. > > Nice work, I'll try to get it in CVS ASAP. > RbdPngn Thanks. I'll have a look at the code to see if i can improve the points we discussed. benoar ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
