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

E. Westbrook gstreamer at westbrook.com
Sun Jul 5 06:44:55 CEST 2009


On Sat, Jul 4, 2009 at 1:37 PM, David Schleef <ds at entropywave.com> wrote:

> 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.
>
>  - Whether Orc will be a required dependency *for developers*.
>
>  - 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.
>
>  - Orc is still developing rapidly enough that it will either
>   need an ABI bump soon or start accumulating crufty API.
>
> 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.
>
> > And what will happen if orc is used on an architecture (mips, alpha, x86
> > without MMX and stuff)? Will orc simply fail then or is there a slow
> > fallback implementation?
>
> It uses the C backup function that orcc generates.
>
> > - The multichannel conversion routines need some kind of matrix
> > operations. Is this what you mean with 2-D array mode?
>
> Partly.
>
> > Will it also be possible at some point to write things like
> > for (i = 0; i < N; i+=2)
> >   d[i] = s[i] + s[i+1]
> > with orc?
>
> You can do that right now using something like:
>
>  select0lw t1, s1
>  select1lw t2, s1
>  addw t1, t1, t2
>  select0lw t3, d1
>  select1lw t4, d1
>  addw t3, t3, t1
>  mergewl d1, t3, t4
>
> It's a little clumsy, but any strided operation is clumsy with
> vector operations.  (Also note that you can't currently read a
> source twice, you have to copy it to a temp variable first, but
> that is a bug.)
>
> 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.
>
>
>
> dave...
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090704/8e5a98ed/attachment.htm>


More information about the gstreamer-devel mailing list