[gst-devel] Orc-0.4.1 - The Oil Runtime Compiler

[Sebastian Dröge]

Am Samstag, den 04.07.2009, 12:37 -0700 schrieb David Schleef:
> On Sat, Jul 04, 2009 at 10:13:14AM +0200, Sebastian Dröge wrote:
> > When do you plan to push this changes to the main GIT repository?
> 
> Probably won't be pushed any time soon.  I'm not planning to write
> or maintain #ifdef HAVE_ORC's everywhere, so it's probably not
> appropriate for master until Orc gets more user testing, cross-platform
> testing, and perhaps a few more features.
> 
> There are several hurdles that need to be addressed:
> 
>  - Whether Orc will be a required dependency *for users*.  Orc
>    will probably grow features soon that makes this irrelevant.

If it's not a dependency for users the CPU feature detection code, etc
must be statically included and called for every single orc program. Not
sure if this is a good idea.

Also one library more or less doesn't make a large difference IMHO.

>  - Whether Orc will be a required dependency *for developers*.

Same as above, one library (+ headers & orcc) more or less doesn't make
much difference.

>  - Whether to make the .orc source the canonical description of
>    the functions implemented.  Pro: orcc automatically generates
>    test code.  Cons: yet more crap for developers to learn, plus
>    the generated C code is not easy to understand.

Also orcc could have a parameter that changes it to output assembly code
for one specific target instead of the JIT-like OrcProgram code. This
probably makes embedded system developers happy ;)

>  - Orc is still developing rapidly enough that it will either
>    need an ABI bump soon or start accumulating crufty API.

Yeah, we should IMHO make orc optional for now until it has matured a
bit.

> The summit would be a convenient time to discuss such things.  I
> don't really need to be involved.  I'm committed to making Orc a
> useful tool for GStreamer, 
> 
> I'm tentatively planning an ABI bump once Orc handles roughly all
> the liboil functions that Schroedinger and GStreamer use, which
> should be some time in September.  Hopefully there will have been
> enough user testing by then that it can be an ABI that is stable
> for several years.

I've also packaged orc a month ago for Debian/experimental so some more
users/tester will probably come from there too (once it's accepted from
the new packages queue).

IMHO another thing that orc has to support until we can drop liboil
everywhere is the CPU feature detection stuff from liboil to enable "3rd
party" assembly code at runtime, like in the goom plugin. Or we should
add some functions for this somewhere in gst core.

> > - The multichannel conversion routines need some kind of matrix
> > operations. Is this what you mean with 2-D array mode?
> 
> Partly.

Great, matrix operations will be very useful for a lot of code I
guess :)

> Concerning the orc Makefile target in you other email, I'm planning
> to make orcc also generate independent C code, so if HAVE_ORC is not
> defined in config.h (for example), the generated code won't need Orc
> headers to compile, nor will you need orcc installed to generate
> those files.  These are tradeoffs that aren't unique to Orc.

As said above I think it's better to generate the C code at runtime (the
embedded systems developers argument, etc above) and another argument
would be that changes to orcc would automatically be applied to all orcc
generated code all over the world ;)

A hybrid solution would be to ship the orcc generated code in tarballs
and have the generation target as in my previous mail. This would make
compilation without orcc possible but when it's installed it can be used
to regenerate the C code (+ maybe a configure switch to force
regeneration).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090705/ba8de06d/attachment.pgp>