[FFmpeg-devel] libavutil simd

Michael Niedermayer michaelni
Tue Oct 2 15:27:56 CEST 2007


On Mon, Oct 01, 2007 at 10:09:10PM -0400, Rich Felker wrote:
> > 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
> What about providing both as 2 separate functions, and documenting
> that the forking function will fork? Or better yet, just read
> /proc/cpuinfo and forget about supporting runtime cpu detection on
> systems without cpuinfo or equivalent.

personally iam in favor of the simplest and least hackish solution
for x86 we can easily and cleanly figure out the cpu capabilities

for ppc and sparc there is no simple and clean way, what really is the
big problem with treating ppc without altivec like a different
architecture than ppc with altivec?
with x86 we cant as there are so many different variants (mmx, 3dnow, mmx2
sse, sse2, ....)

the whole thread seems to be centered around "we must do it at runtime
no matter what" i just cant help but keep wondering why that is so
important? if it can be done cleanly iam all for it but it rathr looks
like we would need 10 different solutions to do it for each different OS
and for another 5 OS would need to fork which many applications 
(other libs) just cant do
i think this outwheights the complexity of considering ppc / ppc-altivec
different architectures, that is for us certainly and from the applications
point of view maybe as well especially for the case where the application
has to figure it out itself

also if people really insist on doing this at runtime against all sanity
we could at least have a
#define PATH_TO_CPUINFO "/proc/cpinfo"
and use that
and non linux OS could then if their users want, create such file
with proper altivec/sparc vis info and a path appropriate for their OS

PS: let me remind everyone that libavutil is supposed to be LIGHTweight,
simple, modular and fast
and i really would rather drop SIMD in libavutil completely before we
fill it up with some of the idiotic hacks suggested by the army of
bloated zombies in this thread. Many of you really sound like win32
users who want their ideas implemented no matter how stupid

PS2: this reply is not really a reply to rich but rather to th whole

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/d856319c/attachment.pgp>

More information about the ffmpeg-devel mailing list