[PD] DSP and Gem in the same instance of Pd

Fri Apr 1 05:07:48 CEST 2016

Slightly OT-- but related:
I'm going to throw out a wish-list item
which is probably impossible or very hard to implement,

Find a way for the DSP Graph compiler to naturally
break up the task into small chunks, which all use shared
memory in a thread-safe way, so that the PD job automagically
spreads itself out over available cores without any special
work by the programmer.

Now that I've got my big, fast, lots of ram, 6-core AMD
box running again, I notice that I can run MUCH larger
graphs there than on my Raspberry Pi.

But I think it's just a raw CPU speed, or Cache Speed, or
speed to RAM which matters, and not the number of cores.

I notice that on my Pi there seems to be two processes, one for
the GUI and one for the DSP. 2 cores are wasted unless I use
the [pd~] object, and I have to basically guess how to split up the job.

I know, I'm dreaming here....

On Thu, Mar 31, 2016 at 10:57 PM, Lucas Cordiviola <lucarda27 at hotmail.com>
wrote:

> And more,
>
> A single thread calculation divided between 2 cores in its 1 core time is
> more stable.
>
> 1 0
> 0 1
> 1 0
> 0 1
>
> transistors have more idle time.
>
> Mensaje telepatico asistido por maquinas.
>
> ------------------------------
> From: brbrofsvl at gmail.com
> Date: Thu, 31 Mar 2016 22:45:57 -0400
> Subject: Re: [PD] DSP and Gem in the same instance of Pd
> To: jancsika at yahoo.com
> CC: lucarda27 at hotmail.com; pd-list at lists.iem.at
>
>
> Right, so the point of [pd~] is that the OS can now throw whatever is
> going on in the subprocess onto another core. The idea from what I've heard
> for Gem is that you can leave the DSP off in the [pd~] instance, run Gem
> from there (on another core, possibly). Then if together they would have
> maxed out one core they could split the work among two and proceed in time.
>
> But if the problem is that Gem has to wait for something to happen
> elsewhere before it can proceed, it won't help. Kind of in the same way
> that running an infinite [until] loop on the subprocess will halt the main
> process, too.
>
> On Thu, Mar 31, 2016 at 9:24 PM, Jonathan Wilkes via Pd-list <
> pd-list at lists.iem.at> wrote:
>
> But [cpu_hungry_hippo~] needs input from [pd~] in order to
> compute its output.  So [pd~] must send output before [cpu_hungry_hippo~]
> can execute its perform routine.
>
>
> On Thursday, March 31, 2016 9:17 PM, Lucas Cordiviola <
> lucarda27 at hotmail.com> wrote:
>
>
> Isn`t
>
> [pd~] <-- some dsp stuff going on in here
>
> To take advantage of multi-core CPUs?
>
> Mensaje telepatico asistido por maquinas.
>
> ------------------------------
> Date: Fri, 1 Apr 2016 00:37:26 +0000
> To: brbrofsvl at gmail.com; reduzent at gmail.com
> CC: pd-list at lists.iem.at
> Subject: Re: [PD] DSP and Gem in the same instance of Pd
> From: pd-list at lists.iem.at
>
> I'm not sure I understand [pd~].  Consider:
>
> [foo~]
> |
> [pd~] <-- some dsp stuff going on in here
> |
> [cpu_hungy_hippo~]
>
> How does [pd~] help me in this case, as opposed to just putting the
> "dsp stuff" directly in the patch?
>
> And in general, how is the super-process able to anything
> other than block when waiting for output from [pd~]?
>
> -Jonathan
>
>
>
> On Thursday, March 31, 2016 5:17 PM, Matt Barber <brbrofsvl at gmail.com>
> wrote:
>
>
> One other thing that's helped in an emergency is increasing Pd's audio
> buffer in the preferences.
>
> One thing I've heard of but never tried is running Gem from a slave
> instance in [pd~]. I don't know enough about it to know whether this could
> work or why; it might just be a rain dance.
>
> On Thu, Mar 31, 2016 at 7:16 AM, Roman Haefeli <reduzent at gmail.com> wrote:
>
> On Thu, 2016-03-31 at 11:35 +0200, cyrille henry wrote:
> >
> > Le 31/03/2016 11:19, Roman Haefeli a écrit :
> > >
> > > BTW: Why does the graphics rendering|clock have precedence over the
> > > audio rendering (at least, it seems to be like that in Pure Data/Gem)?
> I
> > > guess most softwares do it the other way around, since clicks are much
> > > more noticeable than a frame being a few milliseconds late.
> >
> > Gem have no precedence over audio : they both have the same priority.
> > when having priorities on audio, the openGL rendering did not have
> > fixed frame rate, and it's not possible any-more to have smooth hight
> > speed movement.
> >
> > So, i like the way it is, even if it cause implementation problem.
>
> Oh, now since I understand, I like the way it is, too ;-)
>
> > one possible explanation of your problem is that you are rendering a
> > 60 fps, and that openGL is sync on the 60fps screen.
> > You can have jitter between the 2 different 60fps clock. If Gem is
> > waiting for the screen, then everything (including audio) is on pause.
>
> That is exactly what I was doing.
>
> > if this is the cause of your problem, then reduce Gem fps to 59, or
> > remove openGL syncro (sync to vblank).
>
> This is exactly what helped (reducing fps to 59). Thanks for your sharp
> thinking.
>
> Roman
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________ Pd-list at lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160331/fd3ece1f/attachment.html>