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

Jason Garrett-Glaser darkshikari
Fri Sep 24 06:21:22 CEST 2010

On Thu, Sep 23, 2010 at 8:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.

yasm and inline asm are different languages.  Asking someone to port
code from one to the other while keeping it exactly identical is
stupid; it adds an enormous amount of overhead to the process.  In
reality, it isn't really porting; it's rewriting, with some
inspiration gained from the original code.

> So what should i do?
> mans, dark shikari, you and everyone else on irc do a witchhunt against
> inline asm

No, we're submitting patches that improve performance and
compatibility.  It just happens that these move inline asm to yasm.

right whatsoever to reject any of these patches.

> and try to push by sheer force otherwise totally unaceptable
> patches through. what really has happened with the code quality standards?

They're rising as we get rid of your terribly written unreadable asm.

> 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.

But it's a bikeshed argument among developers.  You are not a current
developer of the asm, therefore you have no right to comment on what
color the bikeshed should be.  If you want to comment, get involved
and do something.

> 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?

Because 100% of the developers currently working on this code agree.

> 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?

No, we have many ideas; I already wrote a deblock strength function in
x264 that's over a factor of 2 faster, and once the code is changed to
easily allow yasm instead of inline, we'll be able to port it.  I'm
happy to LGPL it.

> maybe it really is already perfect but in no case in the past have we
> commited code changes mixed into such translations/cosmetics.

"Perfect" doesn't exist.  All that matters is "better".

> 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

That's how open source works.  If every single developer working on X
wants to do Y, they do Y.  Someone who doesn't work on X has no right
to insist that Y not be done.  They have the right to comment, for
sure, but if you don't work on something, attempting to bypass
consensus and hold up development is beyond obnoxious.

Dark Shikari

More information about the ffmpeg-devel mailing list