Hi,

On Mon, Jan 30, 2012 at 3:42 PM, Diego Biurrun <[email protected]> wrote:
> On Mon, Jan 30, 2012 at 11:38:09PM +0000, Måns Rullgård wrote:
>> Diego Biurrun <[email protected]> writes:
>> > On Fri, Jan 27, 2012 at 04:56:24PM +0000, Måns Rullgård wrote:
>> >> Diego Biurrun <[email protected]> writes:
>> >> > On Fri, Jan 27, 2012 at 07:54:36AM +0800, Ronald S. Bultje wrote:
>> >> >> Also convert to yasm, add a loop to add_png_paeth_pred() to handle
>> >> >> the case where bpp>4 (e.g. RGB48), and add a SSE2 version for
>> >> >> add_bytes_l2().
>> >> >
>> >> >> --- /dev/null
>> >> >> +++ b/libavcodec/pngdsp.c
>> >> >> @@ -0,0 +1,50 @@
>> >> >> +
>> >> >> +    if (HAVE_MMX)
>> >> >> +        ff_pngdsp_x86_init(dsp);
>> >> >
>> >> > The arch-independent code should not have to care about x86 
>> >> > implementation
>> >> > details like MMX, YASM or whatever, so just ARCH_X86 should be enough.
>> >> > That said, we are not currently consistent about this.  See also my 
>> >> > remark
>> >> > on the x86 build part below.
>> >> >
>> >> > And yes, I have made a mental remark to look into this.
>> >>
>> >> Almost all the x86 init functions use if(HAVE_MMX).  I looked into it
>> >> once, and changing it to ARCH_X86 got rather messy.
>> >
>> > Unlike ARM there is not always an init function available that is compiled
>> > unconditionally, but AFAICT there is nothing more to it.  I mean all that
>> > should be necessary is writing x86-specific init functions for png and all
>> > the others that get compiled unconditionally and themselves contain all
>> > necessary and appropriate #ifdefs.  Then the arch-independent C code would
>> > call those init functions under an ARCH_X86 check.
>> >
>> > Am I overlooking something?
>>
>> Only that the x86 files are so hideously ugly that the mere thought of
>> touching them makes me shiver.
>
> They are fugly beasts indeed.  The YASM conversion project should get
> this under control eventually.  I'll look into init code refactoring
> when I find a bit of time.

Yasm handles the actual DSP code, not the init code. So the work
should be orthogonal and can be done at the same time, no?

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to