[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] [BUG] SRCALPHA - unexpected behaviour.



In that case I should look at cleaning up the code a bit. I wrote it so MMX/SSE would be easily interchangable. I can add some extra variables so as to not need to manipulate the stack pointer as well as remove some redundancies.

René Dudfield wrote:
ah ok cool.  I think we should try and support older chips... just
because they need the speed up the most.

So the plan is to use the changes for vanilla mmx?

If only we had a run time assembler ;)  like libyasm :)


On 8/23/07, Richard Goedeken <SirRichard@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Actually, according to Wikipedia, every AMD chip since and including the
original Athlon (everything after the K6) has included the MMX
extensions from SSE.  On the Intel side, everything since and including
the P3 has SSE.

Having said that, if you want to support vanilla MMX, another option is
to just remove my original 'SSE/MMX' instructions, keep Mr Lindstrom's
changes, and get rid of the extra config parameter.  The extra makefile
complexity might not be worth it, as his changes will only hurt
performance on modern CPUs by a few percent.  These filtering-type
routines are usually highly memory-bound in performance.

Richard


René Dudfield wrote:
yeah, sse is not everywhere yet.

There are a lot of AMD chips out there without it.  So I think we
should leave the SSE off unless detected.

cheers,


On 8/23/07, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
Glad to here about the MMX. My SSE patch requires SSE support to be
explicitly turned off with a NO_SSE flag. But this is at odds with other
libraries where MMX/SSE support must be turned on: SDL has
MMX_ASMBLIT/SSE_ASMBLIT, smpeg has USE_MMX. These could be hold-overs
from earlier days when MMX/SSE support was less common. It is probably
now safe to assume MMX is available. I am less sure about SSE, thought
the majority of i386 computers in use today likely support it.


René Dudfield wrote:
that's all I got around to doing today... I'll apply the other patches
later (the mmx fixes, and the fromstring() stuff.)

Cheers,

On 8/22/07, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:

24 bit surfaces do work when the flags are 0. It was the SRCALPHA flag
that caused problems, whether pygame was initialized or not. It was just
that when the surface depth was set to 24 bits implicitly, then the
SRCALPHA flag was ignored. If explicitly then the SRCALPHA flag was
processed and pygame segfaulted.


René Dudfield wrote:

ah, I fixed those segfaults in svn.  There were problems with
get_bytesize, and get_alpha too.

I'm not sure why using a bitdepth of 24 doesn't work without
initializing pygame...  So that can still be considered a bug that
needs investigation.






--
Lenard Lindstrom
<len-l@xxxxxxxxx>