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

Reply via email to