Pierre Ossman wrote: > Handling 32-bit and 64-bit in the same .asm might not be realistic. > Having two versions, one per arch, is fine with me. > Well, that's not really the crux of the problem. The crux of the problem is getting the function call stuff right for the 64-bit version. What I'm saying is that, if you want accelerated 64-bit and are going to constrain me to using the existing libjpeg/SIMD code, then I need help sorting out the function call semantics. But I really think you should consider using OML for 64-bit, for the many reasons I enumerated in my previous message.
> As for OML, I take it you want to replace the existing SSE2 code as > well? > We wouldn't necessarily have to. We could use OML only for 64-bit, for now. >> -- 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? > I've successfully used OML on Linux and Mac and Cygwin with GCC 4 and on Win32 with MSVC 2008. It's a lot less of a requirement than requiring NASM v2.00 or later. >> 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? > I mean using intrinsics to do the MMX code paths as well. I really don't like the idea of requiring NASM to build our code. But, as I said, that's a long-term desire. >> 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. > There's a lot of risk in releasing a 64-bit port of libjpeg/SIMD as well. I understand the desire to constrain that risk to only the 64-bit code path, which we could easily do by using OML only for 64-bit. I think that doing that is, in fact, less risky than a 64-bit libjpeg/SIMD port. The only other option is to not have acceleration for 64-bit, and I don't like that idea. Also, irrespective of 64-bit, I still need help figuring out the problem below. > Odd. I guess RGB_PIXELSIZE must have been defined to something strange. > Have you checked that jsimdcfg.inc looks sane? > Yes, it's completely sane. Could you please try setting RGB_PIXELSIZE=4 on your system and see if you can reproduce the problem? ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
