[FFmpeg-devel] [PATCH 3/4] Implement and use shareable ff_transpose function.

[Stefano Sabatini]

On date Saturday 2010-11-27 03:58:53 +0100, Michael Niedermayer encoded:
> On Fri, Nov 26, 2010 at 11:50:16AM +0100, Stefano Sabatini wrote:
> > On date Thursday 2010-11-25 03:26:01 +0100, Michael Niedermayer encoded:
> > > On Tue, Nov 23, 2010 at 09:27:43PM +0100, Stefano Sabatini wrote:
> > > > On date Thursday 2010-11-04 00:54:58 +0100, Michael Niedermayer encoded:
> > > > > On Wed, Nov 03, 2010 at 10:43:56PM +0100, Stefano Sabatini wrote:
> > > > > > On date Thursday 2010-10-28 16:38:35 -0700, Stefano Sabatini encoded:
> > > > > > > On date Thursday 2010-10-21 01:37:38 +0200, Michael Niedermayer encoded:
> > > > > > > > On Mon, Oct 18, 2010 at 02:09:54PM +0200, Stefano Sabatini wrote:
> > > > > > > [...]
> > > > > > > > > So what's the best course of action to follow now?
> > > > > > > > > 
> > > > > > > > > We have three filters (one of which committed: hflip, tranpose,
> > > > > > > > > rotate90) which may share common code during the init stage. Currently
> > > > > > > > > they are in separate files, so which is the best way to make them
> > > > > > > > > share the optimization code?
> > > > > > > > 
> > > > > > > > I dont know but id say hflip and transpose can be optimized and rotate90 should
> > > > > > > > use them somehow
> > > > > > > 
> > > > > > > Provided that right now I don't care about the optims but I want to
> > > > > > > commit the rotate90 filter, I'd stick with my proposed solution as you
> > > > > > > didn't suggest a better one, optims gurus can take what's required
> > > > > > > later if they'll proceed with optimizations.
> > > > > > 
> > > > > > Ping? OK to apply this and leave it to asm-savvy people? 
> > > > > 
> > > > > id say if you dont care about factorizing the code in a way thats easy to use
> > > > > for optims then leave it duplicated
> > > > 
> > > > I'm still waiting for a useful description of how to do that.
> > > 
> > > just drop this patch.
> > > And when you need to transpose elsewhere write the 20 lines of c code there
> > > 
> > > if someone wants to optimize this he can factor or not factor it as it works
> > > out best. But factorizing 2x20 lines now into 140 lines that cannot be
> > > optimized as they are afterwards really is not a good idea.
> > 
> > What's the problem with the optimization? you never explained. I'm not
> > asking how to factorize but how the file layout should be, the reason
> > for which a .c function file can't be optimized is still a mistery to
> > me.
> 
> There is no context that could hold a function pointer or cpu feature mask
> non constant globals are a bad idea.
> redoing cpu detect on every call is also a bad idea.
> where the code is now there exists a context and an init function to do cpu
> detect.

Thanks for the explanation now it's clear. So patch dropped.
-- 
FFmpeg = Funny Fucking Moronic Peaceful Excellent Guru