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

[Michael Niedermayer]

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.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101127/fe404ba2/attachment.pgp>