[PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])

[Roman Haefeli]

On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote:
> On 2/28/07, Roman Haefeli <reduzierer at yahoo.de> wrote:
>         
>         
>         i might be wrong but in my eyes it doesn't make sense to do
>         all the work
>         that could be done in 50ms in only 1.45ms. 
> 
> What?  GEM doesn't use the DSP clock.  It will take as much time as
> needed to render.  

oops. ok....
 
> For example, the current work I have uses three or four 1080i clips, a
> live feed and records to disk and there is no way that all runs in
> 1.45ms.  It takes about 12-15ms!

anyway, i get dropouts when doing gem-rendering, although 'top' tells me
that pd uses only 20% cpu-time. i don't care much about the audio (as
IOhannes mentioned, i could run two instances of pd). the problem is
that the timing is not nice. i'd like to run the patch with 20 frames
per second. but in praxis each cycle needs 70ms, which gives me a
framerate of 14. 

is my gpu too slow? what happens, when the gpu is overloaded? can that
cause pd to stuck?

i attached a little gem-benchmark-test. although you say, gem doesn't
use the dsp-clock, it takes much longer to compute the first block after
a gem-rendering command. why is that? 
and: here on my system, the [realtime] measures up to 70ms, when i go
over [repeat 1400] (under 1400 it's 50ms). the funny thing is, that it
stays around 70ms, even if i set the [repeat] up to 3000 or more. why is
that? here on my system, cpu-time used by pd is always 20%.

sorry to ask you so much...... but i try to understand things a bit
better.......

roman









	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de