[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