[FFmpeg-devel] libavutil simd

[Michael Niedermayer]

Hi

On Tue, Oct 02, 2007 at 01:04:02AM +0200, Luca Barbato wrote:
> Rich Felker wrote:
> > On Tue, Oct 02, 2007 at 12:15:56AM +0200, Luca Barbato wrote:
> >> Michael Niedermayer wrote:
> >>> so please correct me if iam wrong but i dont see how the altivec "detection"
> >>> code in libavcodec could have ever worked short of by pure luck that gcc
> >>> didnt use altivec anywhere when compiling normal c code
> >> you may use -maltivec (-mabi=altivec) only on the files in which you are
> >> effectively using altivec intrinsics.

well, that will make the code slower ...
the bugreports after all proof gcc did generate altivec from normal c code


> >>
> >>> so it really does not seem like runtime altivec detection is possible not
> >>> even with fork and sigill catching or /proc/ with current gcc
> >> Possible is possible, the question is if it's worth the hassle. I always
> >> been on the "don't care" side, so it's fine for me .
> > 
> > For what it's worth, I'm against hacks in the build system as well as
> > dirty unreliable detection methods.
> 
> the build system won't have hacks but proper usage of Makefile 

> (btw it's
> already done for sparc iirc)

and i would immedeatly approve a patch which removes the sigill detection
for sparc, its just noone posted a patch yet ...


[...]
> > e.g. if another project builds libav* in-tree like MPlayer does.
> 
> That is an hack by definition...

indeed and i guess a patch would be welcome by diego ...
that is one which calls/uses ffmpeg configure/Makefile i think?


> 
> > And, for the time being, this still seems to be the
> > preferred way to use libav*... Users of a library should not have to
> > be aware of hacks that library makes to support runtime CPU detection.
> 
> I still consider saner put on an init function (to be run before you do
> ANYTHING) that switches the implementations according to the application
> requirements. How the application figures what to do is up to it.
> 
> Sounds completely off?

letting the application call init_foobar(cpu_capabilities) and leave it
to the app to figure out cpu_capabilities is certainly possible but it
isnt exactly beautifull

but its certainly better then forking behind the apps back

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071002/7c22f049/attachment.pgp>