[FFmpeg-cvslog] r28500 - trunk/libswscale/swscale-example.c

[Aurelien Jacobs]

Michael Niedermayer wrote:

> On Mon, Feb 09, 2009 at 10:48:12PM +0100, Aurelien Jacobs wrote:
> > Ivan Kalvachev wrote:
> > 
> > > On 2/9/09, Diego Biurrun <diego at biurrun.de> wrote:
> > > > On Mon, Feb 09, 2009 at 08:13:55PM +0000, M?ns Rullg?rd wrote:
> > > >> Diego Biurrun <diego at biurrun.de> writes:
> > > >>
> > > >> > On Mon, Feb 09, 2009 at 08:53:27PM +0100, Michael Niedermayer wrote:
> > > >> >> On Mon, Feb 09, 2009 at 07:04:19PM +0100, diego wrote:
> > > >> >> >
> > > >> >> > Log:
> > > >> >> > Add config.h #include for ARCH_X86 definition.
> > > >> >>
> > > >> >> config.h is not a public header there is no way how swscale-example
> > > >> >> could
> > > >> >> include it.
> > > >> >> Please keep in mind this is a example on how people should use swscale
> > > >> >> from
> > > >> >> their code, you wouldnt want them to include our config.h would you?
> > > >> >
> > > >> > Unfortunately this example program was broken in multiple ways.  I fixed
> > > >> > compilation so that at least 'make tests' can run, but yes, it still has
> > > >> > issues.  It contains
> > > >> >
> > > >> >   #if ARCH_X86
> > > >> >
> > > >> > which implicitly relies on config.h being available.
> > > >>
> > > >> Then that should be fixed, not more breakage added.
> > > >
> > > > Do you have bright suggestions?  Is there a way to avoid the
> > > >
> > > > #if ARCH_X86
> > > >     __asm__ volatile ("emms\n\t");
> > > > #endif
> > > 
> > > This instruction clears the fpu registers after they have been used by mmx.
> > > The real question is:
> > > Is this really necessary? Does swscale leave the fpu registers in mmx
> > > state to boost speed on K6?
> > > From quick look in the template it looks like - no.
> > > 
> > > I guess this is ancient workaround for bug fixed long time ago.
> > 
> > It seems to be so.
> > It indeed looks like swscale already does the appropriate emms, so
> > they could be removed from swscale-example.c.
> > Anyway, it don't seem reasonable to require calling apps to do an
> > emms after calling swscale. So in case this emms in swscale-example.c
> > is really required, I would consider this a bug in swscale.
> > So what about attached patch ?
> 
> if you tested this with MMX/MMXEXT enabled and VERY important SSE* disabled
> then ok

I didn't even tried to compile it. I will let this to people who are really
interested in this issue.

Aurel