Hi, Looks like SDL_HasSSE is indeed buggy on SDL 64bit systems.
Seems redhat has a patch for it: https://bugzilla.redhat.com/show_bug.cgi?id=487720 A patch is here: http://cvs.fedoraproject.org/viewvc/rpms/SDL/devel/SDL-1.2.13-rh487720.patch?revision=1.1&view=markup Also there is a patch in SDL 1.3 svn... which is no use to us since we're still on SDL 1.2.x. Sam isn't doing another SDL 1.2.x release for at least another few months. I've added a bug with link to patch at the SDL bugzilla: http://bugzilla.libsdl.org/show_bug.cgi?id=760 I think disabling it for now on 64bit systems, with a comment about this problem is a good idea. Or perhaps putting an ifdef SDL version > 1.2.13 would be ok too. cheers, On Wed, Jul 1, 2009 at 3:53 AM, Lenard Lindstrom <le...@telus.net> wrote: > > Oops, forgot to attach the patch. > > Lenard > > Lenard Lindstrom wrote: >> >> Hi Lorenz, >> >> Yes, it is supposed to be summer where I am too, and actually was hot for >> awhile, but not now. Anyway, to make sure I am clear on this, Rev. 1658 >> crashes when the transform module is imported, but earlier revisions work. I >> assume this means pygame.transform.smoothscale also works. So I am guessing >> it is the call to the SDL function SDL_HasSSE that is causing the problem. >> The attached patch to transform.c, Rev 2447 (release candidate 2) removes >> the SDL_HasSSE call for 64bit intels. Would you give it a try? If it works I >> will commit it to SVN. It is not ideal, but at least smoothscale will still >> use MMX. >> >> Lenard >> >> Lorenz Quack wrote: >>> >>> Hey Lenard, >>> >>> sorry for the long delays but I'm quite busy these days plus the good >>> weather... not many PC hours left. >>> >>> Lenard Lindstrom wrote: >>>> >>>> Hi Lorenz, >>>> >>>> Could you try dropping in SVN rev 1912 of transform.c instead. This >>>> predates the Python 3 updates. This is kind of reaching, but it will >>>> narrow down the search. >>> >>> I tried this out and poked some more at it and it doesn't seem to be py3k >>> related but rather MMX/SSE. >>> The transform.c rev 1657 works and 1658 breaks. >>> Also if I comment out "#define SCALE_MMX_SUPPORT" in any version it works. >>> >>> I don't get this. I keep thinking that something must be wrong with _my_ >>> system otherwise someone else >>> must have encountered this as well. >>> The only thing I could possibly think of is that I installed the sdl-gfx >>> package without the "mmx" USE-flag >>> (I'm running Gentoo) because it is not available on amd64 architecture. >>> >>> By the way. I also tried commenting out all the asm stuff in scale_mmx64.c >>> but it would still crash. >>> So maybe it is something that is going on in transform.c but related to >>> MMX/SSE >>> >>> If you have any other ideas let me know. >>> >>> yours >>> //Lorenz >>> >>> >>>> >>>> Thanks, >>>> >>>> Lenard >>>> >>>> Lorenz Quack wrote: >>>>> >>>>> Hi again, >>>>> >>>>>> >>>>>> you figured this out yet? >>>>>> >>>>> >>>>> not 100% but at least now I get it to compile by following your advice: >>>>>> >>>>>> Easiest way to work around it... >>>>>> Comment out import transform lines in the file: >>>>>> site-packages/pygame/__init__.py >>>>>> >>>>> [...] >>>>>> >>>>>> Perhaps try commenting out the sse/mmx parts? >>>>>> >>>>> >>>>> that seems to be the problem. If I comment out >>>>> >>>>> # include "scale_mmx64.c" >>>>> >>>>> in "scale_mmx.c" it compiles. if I import pygame the interpreter naturally >>>>> complains about undefined symbols but as long as I don't use the transform >>>>> module it seems to work this way as well. of course this is not a >>>>> solution. >>>>> >>>>> For debugging purposes I tried to remove all SSE/MMX code and simply >>>>> implement >>>>> empty dummy functions like this: >>>>> >>>>> void filter_shrink_X_MMX(Uint8 *srcpix, Uint8 *dstpix, int height, int >>>>> srcpitch, >>>>> int dstpitch, int srcwidth, int dstwidth) {} >>>>> >>>>> that also crashed. I find this very confusing and frustrating. So I >>>>> settle with >>>>> the work around for now. >>>>> >>>>> >>>>> thanks again for the help and if I can help with some debug information >>>>> or if you >>>>> have any ideas let me know. >>>>> >>>>> yours >>>>> //Lorenz >>>> >>> >> >
