theora - Jul 2006 - Theora, liboil and Cell processors

Hello all,

On more than one occasion I have advocated the use of liboil over
incorporating mmx code into libtheora.

The two main reasons are:

1) To keep optimisation code in one place and out of the library.
Everywhere else in the Linux world there is a move to centralise in
order to co-ordinate experts and reduce redundancy. This reason does not
seem to find a lot of agreement in Theora as it creates a dependency. I
don't see why this should be any more an issue for Theora than it is for
all other Linux packages. Libtheora is a library about compressed video,
not about processor optimisation.

2) To avoid backing one horse. Writing mmx code into Theora accelerates
it to the lowest common denominator of _most_ processors. It neither
uses the full potential of any additional acceleration methods created
since mmx, nor does it accelerate for Altivec etc. etc. processors.

The reason that I bring this all up again is that I was reading about
the new Cell processor created by SIT. It sounds to me as though the
Cell will have a big impact on Multimedia computers/devices. It also
sounds as though the processor will (no doubt thanks to IBM) accept
Altivec instructions.

If libtheora used liboil then this news would only matter to those
involved in liboil. Those interested in processor-specific optimisation
could check that the Altivec optimisations, which they have written for
Macs, would work for the Cell and libtheora would be optimised
automatically.

Instead we are in a situation where, every time a new instruction set
comes out (or use of an existing set changes), we have to decide whether
to ignore it or duplicate the liboil effort inside Xiph's libraries.

Correct me if I am wrong, but I understand that it would still be
possible to move the new mmx optimisations into liboil and continue down
that path instead.

I may be missing some fundamental arguments against liboil, so please
tell me if this looks to be the case. From what I have seen, liboil
seems a much better solution to the complete optimisation problem than
the approach that we are currently taking.

Aaron

On Tue, Jul 18, 2006 at 10:49:35PM +1200, Aaron Whitehouse wrote:
> On more than one occasion I have advocated the use of liboil over
> incorporating mmx code into libtheora.
I'll try an summarize the current counter-arguments:

Theora, like most video codecs, uses particular algorithms. So it's not 
that using liboil magically provides optimized versions of theora's 
inner loops. It's more that optimized versions of theora's inner loops 
can be developed inside liboil instead of libtheora; they're still 
specific to theora, which is why _theora_ is a keyword in many of 
routines called by the theora-oil branch. This aligns with your 
argument about centralizing expertise, but it's more that some people 
like developing optimized code within the liboil framework than using 
it conveys instant advantages to naive code. Nor would using liboil 
automatically get us optimized versions on other platforms. Someone has 
to write that code either way.

Mike Smith had another complaint, which I will probably mangle, along 
the lines of liboil's brittleness. It takes the approach of trying to 
compile every possibly applicable version for a given architecture
and then doing run-time profiling to choose between them. This is a 
great idea for some applications, but it takes too long to get accurate 
results with data streams the size of what we see in video, and in
practice seems to make the build brittle since any bit-rotted code
path can make somebody's executable go boom.

Finally, the abstract-everything-into-a-library trend you cite with 
linux development is certainly the GNOME idiom. But libtheora is more 
than just a linux library. It needs to be broadly portable (which liboil 
currently is not, although David has said he intends it to be) and even 
within the linux world, not everyone agrees multiple libraries are worth 
the pain for everything. I guess this is just restating the "minimal 
dependencies" argument you refer to.

As far as altivec and other archs go, the framework we're using to 
optionally call mmx and mmxext routines in libtheora and theora-exp
are equally extensible. And I'd certainly like to have altivec, and
arm asm as well.

FWIW,
 -r