On Wed, 01 Apr 2009 03:35:55 -0500 DRC <dcomman...@users.sourceforge.net> wrote:
> I've been looking into porting libjpeg/SIMD to 64-bit, and thus far, > it's making my brain hurt. Converting the register names is easy enough > and can be done through macros, but then the problem becomes how to > handle the different calling conventions (x86-64 usually passes > everything in registers, whereas x86 passes everything on the stack.) > There is a lot of subtlety in how libjpeg/SIMD handles stack arguments, > because it's trying to align things to 128-bit boundaries for SSE2, > etc. I'm having difficulty sorting out exactly what's happening in the > setup portion of each function. > > I'm wondering whether it wouldn't be a better idea to just use Open > mediaLib for the SSE2 code path in libjpeg/SIMD. It's licensed under > LGPL v2.1, so there shouldn't be any legal issues with embedding it. It > would certainly be easier for me, and I think it would be more > maintainable than doing a lot of #ifdefs at the assembly level to > support 64-bit. There are several other key advantages to using OML: > Handling 32-bit and 64-bit in the same .asm might not be realistic. Having two versions, one per arch, is fine with me. As for OML, I take it you want to replace the existing SSE2 code as well? > -- well-proven and well-tested code base > -- builds and runs cleanly as a 64-bit library > -- works on a variety of platforms, including Windows, Linux, Mac, and > Solaris/x86. > -- written in C using SSE intrinsics, thus easier to maintain I'm a bit sceptical about intrinsics. Those have been riddled with bugs, primarily with regard to alignment. Do you have any information on which compilers have implemented these properly? > -- would not require NASM. This is key, because it turns out that > x86-64 support was not added to NASM until v2.0, and thus many platforms > (including RedHat 5) cannot assemble x86-64 code without downloading an > upgrade to NASM, which is somewhat hard to find (the RPMs distributed by > the NASM project don't work on RHEL 5.) Ouch. That is a bit annoying. > > We'd still use the MMX code for 32-bit, for the time being (although I > think I'd like to try porting the MMX code to C as well in the long term > -- after 1.0.0.) What do you mean by porting to C? > Essentially, I think it would take me less time to introduce the Open > mediaLib routines into libjpeg/SIMD than it would to modify the assembly > code to support multiple pixel formats. Bringing in another complex lib into the build right now makes me a bit uneasy. I'd prefer if we could wait until after the release to start looking at OML and if the benefits outweigh the costs. The number of combinations for pixel formats aren't that many. Can't we just automatically generate one function per combination? That design should fit with how the code is written right now. > > Corollary to the above, I am having trouble getting the 4-byte color > conversion code paths in libjpeg/SIMD to compile. For some reason, it's > giving me the following error: > > jccolss2.asm:245: error: comma or end of line expected > jccolss2.asm:250: error: comma or end of line expected > > I'm using nasm v2.05.01. > Odd. I guess RGB_PIXELSIZE must have been defined to something strange. Have you checked that jsimdcfg.inc looks sane? Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com
signature.asc
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
