[PD-dev] GEM development

[Daniel Heckenberg]

> From: g|nter geiger [mailto:geiger at xdv.org]
> Sent: Friday, 14 June 2002 7:30 PM
>
> On Fri, 14 Jun 2002, Daniel Heckenberg wrote:
> > That's good news: those pix_es could definitely be optimized and MMX and
> > Altivec are great for image processing.  How far are you through this
> > process?
>
> Thats a good questions, I have only started. So far I have done the simple
> things like pix_add, pix_sub which got a tremendous speedup.
>
> I have been working with pix_convolve a bit, no asm yet, but by
> specializing to fixed convolution kernels and avoiding
> allocation/deallocation of memory as well as floating point calculations
>  I got a 2-3 fold improvement in speed. The asm code is a bit more complex
> there and I am not a specialist in doing this.

This does get hairy very quickly... in many situations with recent Intel
processors it's faster to use floating point math than integer.  MMX tips
the balance back (particularly for image processing because there's native
saturation mode arithmetic) but SSE gives you SIMD for floating point as
well.

Intel have some highly optimized libraries for image processing (including
2d convolution) which are available for windows and linux.  The licensing
terms may be incompatible with pd (not sure about this) but they would
provide a good performance reference.

> Finally we have to check the pix_ objects step by step,and of course
> non asm version have to be supplied to ....
> maybe investigate on libraries for doing that.
>
> > There are problems in the release code when an dualpix object
> is deleted or
> > its stoprender method is called.
>
> .. ok, now I got it. I think that if you create the left render chain
> first it may work out, thats why the problem only showed up sometimes,
> really great that you were able to figure this out !
>
> I am just looking at the chaining setup (I did this the last time
> some years ago, forgot completely how it worked).
>
> Doing that I am trying to figure out how to reconstruct render chains
> every time the patch is changed, ... would be great if there was
> immediate feedback if the patch is edited.

Yes... I guess this would involve sending messages down the pd connections
and comparing the resultant chain to the existing render chain.  I'm not
sure how slow this would be, altho it wouldn't be hard to check.  Could be
nice as an "edit" mode rather than "performance" mode.

Daniel