[FFmpeg-devel] [PATCH] move h264 loopfilter strength code to yasm

Michael Niedermayer michaelni
Fri Sep 24 05:18:20 CEST 2010


On Thu, Sep 23, 2010 at 06:13:30PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> $subj. This could likely be done in inline asm as well but I still
> can't write that.

can i help you to learn it?


> The advantage of the approach to write it fully in
> asm is to get rid of gcc doing a pretty bad job at optimizing, e.g.

thats great and i dont mind

the problem here is that inline ->yasm and further optimizations
should be seperate patches and you yourself submitted a patch that repeats
this rule, its already in the policy that patches shoudl be cleanly split.
and we all know a dozen reasons why that is so.

So what should i do?
mans, dark shikari, you and everyone else on irc do a witchhunt against
inline asm and try to push by sheer force otherwise totally unaceptable
patches through. what really has happened with the code quality standards?
and when i complain iam included in that hunt
inline vs yasm is bikeshed, and i oppose not yasm but the drunken mob that
pretends yasm is better for cases where obviously it is pure bikeshed what
to use.
Also i oppose people who come here with "This could likely be done in the
used style but i cant write that so i changed the whole file to new style
and in the same patch added optims"

Everyone please take a look at what you are doing and think about it
If someone added 4:2:2 and 4:4:4 support to h264 but rewrote the whole
to C++ with a comment that he doesnt know C, we wouldnt accept it but
demand it seperated
So why is everyone blind when its inline->yasm?

I like to review the optimizations, but i cannot because they are hidden in a
huge inline->yasm translation done by you
do you think noone has ideas to improve the optimization you add further so
that it doesnt need review?
maybe it really is already perfect but in no case in the past have we
commited code changes mixed into such translations/cosmetics.
And here its happening with trolls on irc just saying "ignore michael, commit
it"
Ignore me if you like but use your f*cking brain, dont just behave like
a lemming following the majority on irc without any single one thinking

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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/20100924/41a8d4cd/attachment.pgp>



More information about the ffmpeg-devel mailing list