Hi, On Tue, Jul 24, 2012 at 7:25 AM, Luca Barbato <lu_z...@gentoo.org> wrote: > On 7/24/12 4:45 AM, Ronald S. Bultje wrote: >> >> Hi, >> >> On Mon, Jul 23, 2012 at 7:45 PM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >>> >>> Hi, >>> >>> On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang <daniel.d.k...@gmail.com> >>> wrote: >>>> >>>> On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun <di...@biurrun.de> wrote: >>>>> >>>>> >>>>> On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote: >>>>>> >>>>>> From: Daniel Kang <daniel.d.k...@gmail.com> >>>>>> >>>>>> The only CPUs that have 3dnow and don't have mmxext are 12 years old. >>>>>> --- >>>>>> libavcodec/x86/dsputil_mmx.c | 9 --------- >>>>>> libavcodec/x86/h264_qpel_mmx.c | 4 ---- >>>>>> 2 files changed, 0 insertions(+), 13 deletions(-) >>>>> >>>>> >>>>> What sort of maintenance burden does this relieve us from? >>>>> I'm writing this mail on a system fitting the description >>>>> you mention, my trusty old K6-III. >>>> >>>> >>>> >>> [..] >>>> >>>> 4. You can probably decode 260p H.264 with a K6-III. Who seriously would >>>> use >>>> this? >>> >>> >>> This really is the killer. Is there any sort of reasonable expectation >>> that a k6-3 can get useful work done when it comes to H264 decoding? I >>> wouldn't even mind dropping all MMX optimizations (where MMX2 - i.e. >>> SSE - or higher exists) altogether, i.e. going the H264 way >> >> >> .. x264 way. :). > > > Let's discuss a bit or put a news item, the pros is to having a leaner > system, the cons is cutting dry systems that might work fine for special > purposes now. > > If we can have some compelling improvement (e.g. yasm) why not?
The alternatively that I have suggested to Daniel is to keep the old inline asm code for 3dnow only. The disadvantage of that is that we keep pretty much all code around, just for 3dnow alone, and duplicate it in yasm form for all other optimization types. So it's practically possible, but at a high cost (+ that since it's duplicated, it'll be orphaned and unmaintained; any improvements to the new qpel code will not hit the 3dnow optimizations). Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
