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

Sebastian Dröge sebastian.droege at collabora.co.uk
Sat Jul 4 01:17:49 PDT 2009

Am Samstag, den 04.07.2009, 10:13 +0200 schrieb Sebastian Dröge:
> Am Donnerstag, den 02.07.2009, 15:34 -0700 schrieb David Schleef:
> >
> > [...]
> > Much of Schroedinger and GStreamer have been converted to use Orc
> > instead of liboil, as well as converting code that wasn't able to
> > use liboil.  To enable this in Schroedinger, use the --enable-orc
> > configure option.  The GStreamer changes are in the orc branch in
> > the repository at http://cgit.freedesktop.org/~ds/gstreamer
> When do you plan to push this changes to the main GIT repository? Also,
> will orc be an optional dependency?
> 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?
> Oh, and I saw you started to convert audioconvert to orc. If you want to
> continue this just some notes:
> - The dithering can also be done as a simple addition from some random
> values array. This could be initialized once when the format changes and
> be used as a read-only ring buffer, it just has to be large enough. This
> should make it possible to also implement the dithering with orc.
> - The multichannel conversion routines need some kind of matrix
> operations. Is this what you mean with 2-D array mode?
> > Scheduled changes for 0.4.2 include a 2-D array mode for converting
> > the remaining liboil functions used in Schroedinger and GStreamer.
> 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?

And something else, I saw that you only added a static "orc" target to
the gst Makefiles. Wouldn't it be better to have a rule like

gstorc.c gstorc.h: gstorc.orc
	orcc gstorc.orc
	mv out.c gstorc.c
	mv out.h gstorc.h

And then gstorc.c in the _SOURCES variable? A dependency on orc is
needed anyway for linking so orcc should be available and the above
would make sure that the C sources are regenerated when the ORC sources
change. Also it's a bit ugly to ship autogenerated code in the tarballs
later IMHO :)
-------------- 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/liboil/attachments/20090704/bdb52b8e/attachment.pgp 

More information about the Liboil mailing list