On Mon, 22 Aug 2005 19:43:58 +0000 Tiago Victor Gehring <[EMAIL PROTECTED]> babbled:
> ok, found another line with the same problem - I saw this after seeing > another post reporting also a amd64 issue with emblem and trying to > start emblem myself... > Now, before submiting another patch (emblem actually worked after > changing one more instruction) I just wanted to speculate about the more > general solution to this problem (I'm by no means an assembly expert, > just did some reading on the net and took a better look at the code): > What I think is that the problem with memory alignment resides only in > the lines where data is copied from/to addresses using (RIP) relative > addressing (at least it was the case in the lines that I changed before > and now again). > I mean, the problem is not with the source/destination pointers > (parameters) because the assembly code already checks if these pointers > are aligned and uses the best instruction acording to the case (and sure > the performance drop for coping unaligned memory is really big), the > lines that gave problems where just the ones that use something like > "movdqa 0xXX(%rip),%xmmN"; > > The question is, there are a lot of other points of the code where a > aligned copy to/from a relative address is made, should all of them be > changed to unaligned or is there another solution? > As said, all of this is just a suposition... actually do tests - you may find the unaligned copies not that much slower as traditionally x86 hw has always done the fixups for unaligned read/writes in hardware and thus the overhead is fairly small. > > On Mon, 2005-08-22 at 07:45 -0600, Tres Melton wrote: > > On Mon, 2005-08-22 at 07:29 +0000, Tiago Victor Gehring wrote: > > > Hi, > > > regarding the problem I mentionted about the new amd64 optimized > > > functions in imlib2, I think I found the problem, has something to do > > > with the fact that memory was not aligned in some (SSE2 128 bit) MOV > > > operations - ie, I just changed a couple of MOVDQA to MOVDQU in file > > > amd64_blend.S, treating memory as unaligned; > > > Now if this has some other side effects (speed?) I don't know, but for > > > me it worked now... > > > > > > Cheers, > > > Tiago Gehring > > > > > This is a poor solution in terms of speed. The correct solution is to > > ensure that the memory is properly aligned. For the time being it > > should be left that way (I noticed that raster committed the move > > unaligned data change). I have spoken with vapier (briefly) about it > > and am hoping to force the memory to be aligned on 128 bit boundaries. > > This will impact the stack size of the code and a few other things that > > I want to look into before offering a patch. A couple of hints: > > > > SSE instructions should be aligned on 16 byte (128 bit) boundaries. > > MMX instructions should be aligned on 8 byte ( 64 bit) boundaries. > > > > ASM: > > .align 16 > > > > C: > > Image * __attribute__ ((aligned (16))) image; > > > > Regards, > > RiverRat > > > > > > _______________________________________________________ > Yahoo! Acesso Gr疸is - Internet r疳ida e gr疸is. > Instale o discador agora! http://br.acesso.yahoo.com/ > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 [EMAIL PROTECTED] Tokyo, Japan (東京 日本) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel