Re: [PATCH] Re: [pygame] Smooth Scaling (pygame.transform.smoothscale)

[Richard Goedeken <SirRichard@xxxxxxxxxxxxxxxxxxxxxxx>]

That's a good plan, but I haven't been able to find a good way to
determine at compile time whether or not the compiler supports MMX.  You
could always dump out a small test file and compile it to test for
errors, but I was hoping to find something better like running gcc with
a magical parameter or testing for a magical preproc definition.  Are
you aware of any 'cleaner' ways of handling this detection?

Richard


René Dudfield wrote:
> Hi,
> 
> that's good :)
> 
> SDL does it by compiling the mmx stuff in if the compiler supports it.
> Then it has runtime checks to see if the cpu supports it.  SDL also
> has a configure flag, which you can use to tell it not to even try
> compiling mmx stuff.
> 
> So if the compiler doesn't support it, the C version is used.
> If the compiler supports it, and the runtime cpu detection finds mmx,
> then the mmx version is used.
> 
> 
> 
> On 6/20/07, Richard Goedeken <SirRichard@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Rene,
>>
>> I would be willing to add the CPU detection functions but I can't think
>> of how it could be implemented in a useful way.  The compile-time checks
>> have to stay in because trying to compile the 64-bit code on a 32-bit
>> architecture, or the 32-bit MMX code on a PPC or similar, will cause
>> compile-time errors.  So it's given that if someone is running an i386,
>> PPC, Sun, Arm, etc, they will get the C code.  If they're running i686,
>> they'll get the 32-bit MMX, and for x86_64 they'll get the 64-bit MMX.
>>
>> So, the dilemma is that whatever build a user is running, the code is
>> pretty much guaranteed to work on their CPU.  If someone is running the
>> i686 build on a 486 or something silly like that they'll probably have
>> bigger problems.  We could allow someone to 'downgrade' and run the C
>> code when their CPU supports MMX, but what's the point?
>>
>> Regards,
>> Richard