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

Michael Niedermayer michaelni
Fri Sep 24 13:07:40 CEST 2010


On Thu, Sep 23, 2010 at 09:21:22PM -0700, Jason Garrett-Glaser wrote:
> 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

this just is not true, the overhead is pretty much zero.
you and ronald may be active and i am currently notbut that doesnt make the
earth flat and the sun circle it.

as example for the 99% lemmings who belive the loudest with disabled brain

asm(
    "mov a b\n\t"
    "mov c d\n\t"
);
for(i=0; i<2; i++){
    asm(
        "xor a b\n\t"
        "xor c d\n\t"
    );
}

translation to yasm:

-asm(
-    "mov a b\n\t"
-    "mov c d\n\t"
-);
+mov b a
+mov d c
 for(i=0; i<2; i++){
-    asm(
-        "xor a b\n\t"
-        "xor c d\n\t"
-    );
+    xor b a"
+    xor d c
 }


 optimiziong the for loop:
 

 mov b a
 mov d c
-for(i=0; i<2; i++){
+mov x 2
+.next
     xor b a"
     xor d c
-}
+    dec x
+    jnz .next

theres nothing hard on doing it that way


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

> YOU ARE NOT MAINTAINING ANY OF THIS CODE.  Therefore, you have no
> right whatsoever to reject any of these patches.

the solution


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

spare me of that nonsense please
you even agree its bikeshed below


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

for inline vs yasm its bikeshed
for commiting code translations together with optimizations its not
bikeshed


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

this doesnt mean they are right and everyone else is wrong
or that its a good idea to ignore what i have to say with such
aggressiveness that you use in this mail and on irc


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

and iam happy if it is ported, but you know that



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

being able to review changes helps


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

yes and thats why commercial software is higher quality than foss in these
areas. dumping everyone who happens to have been busy for too long and
ignore him entirely is not that good. People dont all of a sudden loose
their knowledge and experience and are better ignored when others become
more active


> They have the right to comment, for

mans and you are loudly complaining about my comments on irc


> sure, but if you don't work on something, attempting to bypass
> consensus and hold up development is beyond obnoxious.

iam at no point holding up development, i gave my oppinion i did make no
attempt to block any commits by force

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/1cfafd18/attachment.pgp>



More information about the ffmpeg-devel mailing list