[MPlayer-dev-eng] shared liba52 and mm_accel macros
Finn Thain
fthain at telegraphics.com.au
Wed Apr 4 10:26:03 CEST 2007
Guillaume Poirier wrote,
> >
> > AFAIK only Altivec is so problematic, and actually only Altivec on
> > Linux, OSX seems to have a special syscall to check for it IIRC.
>
> Yes!
>
> For what it's worth, here's what's implemented in x264 to detect Altivec
> capabilities on OSX:
>
> uint32_t x264_cpu_detect( void )
> {
> /* Thank you VLC */
> uint32_t cpu = 0;
> int selectors[2] = { CTL_HW, HW_VECTORUNIT };
> int has_altivec = 0;
> size_t length = sizeof( has_altivec );
> int error = sysctl( selectors, 2, &has_altivec, &length, NULL, 0 );
A search tells me that this is apple's sample code.
http://developer.apple.com/hardwaredrivers/ve/g3_compatibility.html
I don't know what it does under Rosetta (and it doesn't matter much).
One possible solution would be to add a similar sysctl to Linux, so that
libs could invoke the altivec code without having to be told. But that
won't help in the short-term, even if the distros back-ported it. And it's
probably pointless unless mm_accel selectors were to be deprecated too.
So I guess I'll have to try to get mm_accel.h changed anyway.
-f
> if( error == 0 && has_altivec != 0 )
> {
> cpu |= X264_CPU_ALTIVEC;
> }
>
> return cpu;
> }
>
>
>
>
> on Linux, it's much more hackish (trying to execute an altivec
> instruction and trap SIGILL if it raises an exception.
>
> Guillaume
More information about the MPlayer-dev-eng
mailing list