Ooops ... I just got this email today ... ?! Strange lag. Selon Carsten Haitzler <[EMAIL PROTECTED]>: > > > we do. mmx2 and altivec can do better with 128bit registers - but we have > no > > > code to make use of that at the moment. i personally am willing to live > with > > > this minor error in return for the speedup. you CAN disable mmx, sse > (and > > > altivec) to get the raw C version which is pretty accurate :) > > > > > > > I'm ok with leaving these computations like that if you are ;) I'd like to > > > improve precision by fully using the 128 bits altivec registers, but i > admit i > > didn't get all the "tricks" you used to do the division by 255 in the mmx > > version. As altivec instructions differ from mmx one, i found my way by > > testing some code and looking at the result, and keeping the formula that > > suited the best ... yes that's not the best way to code, but as I was a > SIMD > > newbie at this time ... > > well really with 128bits.. you could increase speed even more by doing 2 > pixels > at once... assuming u have a full 8x16 set of commands (ie add/sub/mul/shift > the > 8 16bit words within the register, just like mmx/altivec can do it in 64bit > registers with 4x16... :) ) i'd go for the speed myself :) > I'm actually doing so : if I remember well (don't have the code here at work) I do 2 pixels at a time when blending (in fact 4 when blending 2 pixels on 2 pixels), and 16 when copying (altivec has 32 registers, each 128bits long... there's always lot of registers on powerpc :-)
> > I just looked at memprof : it seems to be very linux specific. But I'll try > it > > soon, as can't test it while at work ... > > But this problem doesn't seem to come from evas: I tried MallocDebug and > other > > MacOSX tools that say that there's no leaks ! It's really strange, and i > first > > would like to know if it happens only on my mac or not ... > > just because it uses up ram doesn't mean its a LEAK. a LEAK detected by a > leak > detector will find memory where the code has LOST the pointer TO that > memory. > this could be memory the code still has pointers TO (it hasn't lost it) so > what > you NEED is a memory PROFILER. something that tracks every allocation and > there > it was allocated (ie the call tree and line number/file) and then you look > at > the profile and see where the largest amount of memory is being allocated > and > then you know what it is thats eating up the memory (for example a large list > of > images that just keeps being appended to) and you can track further and find > why > it isn't being cleaned up. > Yes, that's maybe not a leak, but the memory usage never decrease, it always increase with time. I expected some memory to be released when the evas demo goes from the graphics intensive intro to the simpler tests. And I never saw this kind of memory usage on my athlon. When I say a lot, this is about 100 MBytes of RAM before the end of the first part of the demo. After that, the system swaps, but I see that the virtual memory of the process keeps increasing. I made a link between the memory usage and the creation of smoothed scaled images. Especially, when the "mire" (I don't know how to say that in english ... the image of some later test in the demo, which is used to demonstrate image scaling) is zoomed out. At this time, the memory usage increase very quickly. On other tests where images aren't needed, the memory usage is quite stable. But that doesn't come from my code: there's the same problem with the C code ! > > > > consuming functions), apart from the malloc/free routines that come > here > > oh - forgot to mention, the EFL stuff is VERY heavy on free/malloc - evas > too. i > would consider trying to optimise this and reduce free/malloc's - maybe move > a > lot of mallocs to calloc (ie allocate on the stack) or remove the need > entirely, > introduce some more optimal memory pools for things like evas_list to use > for > list nodes etc. but gnu libc malloc/free seem very fast and i haven't seen a > need to do a lot of work on this yet. this may not be the case for macosx > though. > Well, I did that for the buffers that are used when "dirty rectangles" are asked by the display system, to avoid swapping too much; I allocated a static buffer large enough to fit all the largers updates. But that's not a solution; that was a temporary "fix". I'm not aware of any speed issue with malloc/free on MacOSX, but maybe that come from here. But I fell like MacOSX is _slow_ in general (well, slow isn't the right word; "not very reactive" would better suit it) > > > > 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. > > > > > > > I thought one day I could try looking at Quartz and maybe do a Quartz-evas > > > engine for it, but Apple hasn't got very detailled doc on low-level > graphics. > > And as one would say on linuxfr.org, "sapusaipalibre". > > i have no objections to a quartz native engine at all. i think it would be > great > actually. but i possess no mac boxes and don't really have any incentive to > work > on it myself :) > Me too ... too much work for now, and I'm not very interested in it. As someone said, porting evas to macosx is maybe not very relevant as OSX's display system is already quite good. But evas will be better ;) I think it's mostly usefull for linux-ppc users; and that's why I'm working on the common part between the 2 worlds: altivec. So, I'm always cleaning up things in my patch, but it's quite a "long" time since I said I would send it; I didn't work a lot on it these days, so I'll try to speed up a bit. I will try for tomorrow ... ! Anyways, it will need further corrections, so let send it not too late. 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
