[gmpi] Re: Topic 7: Audio packaging, Process-In-Place

From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Date: Sat, 31 May 2003 08:58:17 +1200
> > Still better is to have the host decide whether the plugs will run
in-place
> > or not. This is the point that Steve and I have been making.

And Jeff.

I asked how batton-passing handles 'Y connections'.

The answer is: Mark input buffers read-only. Downstream plugins then have to
create a new output buffer each.

2 problems with that:
1) It's not the optimal solution (the 'last' plugin to use the input buffer
could have safely recycled it).

>>"Or you can flag one as read-only and enforce (in your host) that the
in-place plug (non-read-only) run last (but that is pretty ugly)."

Yeah.......I'm trying to avoid "pretty ugly".


2) These 2 new buffers, are they read-only?........

Answer: It depends on the graph layout.  If an output feeds a 'Y junction'
it's read-only.

It keeps coming back to "Only the host knows the graph layout".  Only the
host knows where Y connections are (and yes, they are common).  Only the
host knows the order of execution.  i.e that that last plugin to read a
buffer can safely re-use it via process-in-place.

The more I think about it, the more I realise baton-passing dosn't save any
memcopys, it dosn't save any buffers, it just allows the plugin defer the
problem to someone else (either the host or the next plugin downstream).

I'm not ruling out performance gains from Process-in-place (that's a
seperate issue).

There is zero performance gain from batton-passing. zero.

There is only greater complexity, and slightly less performance due to the
bookeeping overhead and extra indirection.  Do we want all buffers accessed
by a pointer-to-a-pointer?  That's a performance hit on every single plugin,
every single process() call.

"Worse performance than VST", catchy advertising phrase?

Batton-passing is an optimisation for 'corner cases', (plugins that do
nothing but pass an input signal un-modified to an output).  Yet penalises
all other plugins.

> > .... unbundle and re-bundle signal-sets
> > (baton-passing makes this become almost 0 cost)

I would suggest that plugins that "un-bundle signal sets" are not really
plugins, they are simply 'connections' they can be optimised-away to
nothing.

Best Regards,
Jeff



----- Original Message ----- 
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Saturday, May 31, 2003 6:54 AM
Subject: [gmpi] Re: Topic 7: Audio packaging, Process-In-Place


> > of a Y, running a non-in-place plug first, then the in-place plug. If
both
> > are in-place a copy has to be made before running either. If both are
> > not-in-place then it's moot.
>
> The point I keep seeing is that a global I process in-place applies only
to
> simple plugins.  That is probably the vast majority of plugins.  If
> process-in-place is decided by the host, it needs to enforce ordering such
> that only the last effect run is in-place.  If it is not optional to the
> host (that is, if a plugin ALWAYS processes in place) then marking inputs
as
> read-only is actually a win.
>
> If you have to make one buffer copy you use up extra memory bandwidth.  If
> you have to ask for a new buffer for your output because your input is RO,
> you use up more memory, more cache, but NOT memory bandwidth (cache
effects
> aside).
>
> > Still better is to have the host decide whether the plugs will run
in-place
> > or not. This is the point that Steve and I have been making.
>
> The only support for this statement is shared inputs.  Baton-passing has a
> reasonable answer to that (ro buffers).
>
> There are other arguments aginst baton-passing.  Steve thinks the
complexity
> is too high.  I disagree, more or less.  I just want to make sure the
> arguments FOR it and AGAINST it are distilled to their actual value,
before
> I let people discard it as an overly-complex new-fangled idea.  People are
> scared of change, I just don't want THAT to be a factor in the decision.
>
> At this point we're close to pure merit arguments ;)
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules:  Please stay on topic.  You are responsible for your own
> words.  Please respect your fellow subscribers.  Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
>
>


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Follow-Ups:
- [gmpi] Re: Topic 7: Audio packaging, Process-In-Place
  - From: Tim Hockin
References:
- [gmpi] Re: Topic 7: Audio packaging, Process-In-Place
  - From: Tim Hockin
[gmpi] Re: Topic 7: Audio packaging, Process-In-Place

Other related posts:
