On 7/24/12 4:27 PM, Ronald S. Bultje wrote:
Hi,
On Tue, Jul 24, 2012 at 7:25 AM, Luca Barbato <[email protected]> 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 <[email protected]>
wrote:
Hi,
On Mon, Jul 23, 2012 at 5:37 PM, Daniel Kang <[email protected]>
wrote:
On Mon, Jul 23, 2012 at 5:21 PM, Diego Biurrun <[email protected]> wrote:
On Mon, Jul 23, 2012 at 05:12:23PM -0700, Daniel Kang wrote:
From: Daniel Kang <[email protected]>
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).
3dnow could be dropped and we should leave a note "if you need 3dnow you
can reimplement it from looking at ${hash}"
mmx mmx2 and higher I'm not sure if via or whatever has just a selection
of extensions. We could check and see.
The idea of dropping something that might well be cruft is fine IMHO.
lu
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
