Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] 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 frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 - check if it goes higher than 50ms; #X obj 217 298 cube 0.02; #X obj 217 211 translateXYZ -0.001 0 0; #X obj 217 263 translateXYZ 0 0 0.02; #X obj 31 249 bang~; #X obj 31 276 t b b; #X obj 31 300 realtime; #X obj 31 326 t b f; #X obj 31 350 f; #X obj 58 351 + 1; #X obj 31 379 pack f f; #X obj 99 245 gemhead; #X obj 99 270 b; #X obj 99 293 0; #X floatatom 31 434 0 0 0 0 - - -; #X floatatom 85 435 0 0 0 0 - - -; #X floatatom 127 435 0 0 0 0 - - -; #X floatatom 171 436 0 0 0 0 - - -; #X floatatom 214 436 0 0 0 0 - - -; #X floatatom 255 437 0 0 0 0 - - -; #X text 37 457 1; #X text 94 458 2; #X text 135 458 3; #X text 180 459 4; #X text 225 459 5; #X obj 31 403 route 0 1 2 3 4 5; #X text 262 459 6; #X text 28 477 realtime measured lenght of the nth dsp-cycle after the [gemhead] starts rendering.; #X obj 216 129 rotateXYZ 0 0 90; #X obj 216 187 repeat 2000; #X text 55 17 - rendering on/off; #X floatatom 380 146 5 0 0 0 - - -; #X text 425 143 - try different 'loads'; #X connect 1 0 2 0; #X connect 1 1 8 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 41 0; #X connect 5 0 42 0; #X connect 6 0 9 0; #X connect 8 0 0 0; #X connect 9 0 7 0; #X connect 10 0 11 0; #X connect 12 0 16 0; #X connect 15 0 12 0; #X connect 16 0 14 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 18 1 19 1; #X connect 19 0 20 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 21 0 23 0; #X connect 22 0 21 1; #X connect 23 0 38 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 26 0 21 1; #X connect 38 0 27 0; #X connect 38 1 28 0; #X connect 38 2 29 0; #X connect 38 3 30 0; #X connect 38 4 31 0; #X connect 38 5 32 0; #X
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
hello cyrille thank you for the adjustments. i think i understand the difference between measuring the gemhead loop and the time between 2 images. but the other thing with the optimization still remains unclear to me and it seems, that it doesn't work here. when i stop the first and start the second gemhead, the gemwin becomes black. no primitives are drawn. there is no error in the pd-window (there is only a message '[GEMglNewList]: mode=4864' when i load the patch). does the optimization need some flags enabled when compiling gem? it seems, there is so much about gem, i don't know yet (like all these objects [GEMgl*] and [GLdefine] and the like, or the message 'FSAA 4'). to understand them, is it needed to know opengl well? are these objects documented somewhere in the Gem-documentation? i am not insulted if you don't have the time to answer all these questions... cheers roman On Thu, 2007-03-01 at 11:18 +0100, cyrille henry wrote: i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] 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 frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 - check if it goes higher than 50ms; #X obj 217 298 cube 0.02; #X obj 217 211 translateXYZ -0.001 0 0; #X obj 217 263 translateXYZ 0 0 0.02; #X obj 31 249 bang~; #X obj 31 276 t b b; #X obj 31 300 realtime; #X obj 31 326 t b f; #X obj 31 350 f; #X obj 58 351 + 1; #X obj 31 379 pack f f; #X obj 99 245 gemhead; #X obj 99 270 b; #X obj 99 293 0; #X floatatom 31 434 0 0 0 0 - - -; #X floatatom 85 435 0 0 0 0 - - -; #X floatatom 127 435 0 0 0 0 - - -; #X floatatom 171 436 0 0 0 0 - - -; #X floatatom
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
Roman Haefeli a écrit : hello cyrille thank you for the adjustments. i think i understand the difference between measuring the gemhead loop and the time between 2 images. but the other thing with the optimization still remains unclear to me and it seems, that it doesn't work here. when i stop the first and start the second gemhead, the gemwin becomes black. no primitives are drawn. there is no error in the pd-window (there is only a message '[GEMglNewList]: mode=4864' when i load the patch). does the optimization need some flags enabled when compiling gem? ous, sorry, it a bug in my patch. you just need to click on a bang : in the pd optimmized primitive windows : the top one. it should work if you click in this bang after starting the 2nd gemhead. it seems, there is so much about gem, i don't know yet (like all these objects [GEMgl*] and [GLdefine] and the like, or the message 'FSAA 4'). FSAA 4 is only here to enable antialiasing : the result is a much nice image if your hardware suport it. to understand them, is it needed to know opengl well? are these objects documented somewhere in the Gem-documentation? all GEMgl* object are direct wrapper for openGL fonctionnality. so a openGL book is the best documentation. the red book is well known to be the reference. but to be honest, it never try to understand how exaclty does the display list work in Gem, i just cut and paste. cyrille i am not insulted if you don't have the time to answer all these questions... cheers roman On Thu, 2007-03-01 at 11:18 +0100, cyrille henry wrote: i made some change to this abstraction in order to compute only the time use for the gemhead loop and not the time between 2 images. on my computer, it's about 11ms. but with the display list optimisation, it fall to 6ms about. cyrille Roman Haefeli a écrit : as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] 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 frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 -
Re: [PD] spread Gem-computation over several dsp-cycles (?)
Frank Barknecht a écrit : Hallo, cyrille henry hat gesagt: // cyrille henry wrote: don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in : repeat 1000 [ GEMglCallList I've never hear of this optimization, do you have an example for it? here is an exemple that iohannes send to the list time ago. it should be use like a normal primitive. cyrille Ciao #N canvas 232 98 791 542 10; #X obj 37 279 inlet gemlist; #X obj 37 384 outlet gemlist; #X obj 419 180 inlet size; #X obj 505 180 inlet slice; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f \$1; #X obj 347 119 f \$2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 37 246 disk 1; #X obj 37 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 173 translate 1 0 0 1; #X obj 37 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 2 0; #X connect 1 0 7 0; #X connect 2 0 15 0; #X connect 3 0 20 0; #X connect 4 0 24 0; #X connect 5 0 17 0; #X connect 6 0 21 0; #X connect 7 0 5 0; #X connect 7 1 6 0; #X connect 8 0 2 1; #X connect 8 1 9 0; #X connect 8 2 10 0; #X connect 9 0 15 1; #X connect 9 1 16 1; #X connect 10 0 12 1; #X connect 10 1 11 1; #X connect 12 0 16 0; #X connect 13 0 12 2; #X connect 13 1 11 2; #X connect 14 0 2 2; #X connect 14 1 13 0; #X connect 15 0 12 0; #X connect 16 0 11 0; #X connect 17 0 18 0; #X connect 17 1 20 1; #X connect 18 0 19 0; #X connect 19 0 20 0; #X connect 20 0 8 0; #X connect 21 0 22 0; #X connect 21 1 24 1; #X connect 22 0 23 0; #X connect 23 0 24 0; #X connect 24 0 14 0; #X restore 186 467 pd closedcylinder; #X obj 186 221 GEMglGenLists 1; #X obj 156 398 GEMglNewList; #X obj 37 322 GEMglCallList; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 186 199 pd once; #N canvas 0 0 450 300 once 0; #X obj 91 62 inlet; #X obj 91 266 outlet; #X obj 91 150 spigot 1; #X obj 91 175 t a b; #X msg 121 197 0; #X obj 298 57 inlet open; #X obj 298 92 t b; #X msg 142 128 1; #X connect 0 0 2 0; #X connect 2 0 3 0; #X connect 3 0 1 0; #X connect 3 1 4 0; #X connect 4 0 2 1; #X connect 5 0 6 0; #X connect 6 0 7 0; #X connect 7 0 2 1; #X restore 156 372 pd once; #X obj 419 201 t b f; #X obj 505 202 t b f; #X obj 235 354 loadbang; #X obj 235 373 GLdefine GL_COMPILE; #X msg 230 178 bang; #X obj 156 488 GEMglEndList; #X obj 156 425 t a a; #X obj 186 446 separator; #X obj 156 113 gemhead 1; #X obj 316 267 t b; #X obj 156 138 t a a; #X obj 286 241 t f b; #X obj 165 268 t f f; #X msg 305 343 bang; #N canvas 0 0 450 300 closedcylinder 0; #X obj 37 9 inlet gemlist; #X obj 37 274 outlet gemlist; #X obj 301 73 loadbang; #X obj 37 112 cylinder; #X obj 290 30 inlet size; #X obj 376 30 inlet slice; #X obj 261 118 f \$1; #X obj 347 119 f \$2; #X obj 301 92 t b b; #X obj 135 93 t f f f; #X obj 110 118 t f f f; #X obj 168 118 t f f; #X obj 67 246 disk 1; #X obj 67 199 disk 1; #X obj 185 72 t f f; #X obj 152 47 t f f; #X obj 37 131 t a a; #X obj 67 151 separator; #X obj 67 173 translate 1 0 0 1; #X obj 67 223 translate 1 0 0 -2; #X obj 261 141 t f f; #X obj 261 161 0; #X obj 261 181 select 1; #X obj 261 200 f; #X obj 347 141 t f f; #X obj 347 161 0; #X obj 347 181 select 1; #X obj 347 200 f; #X connect 0 0 3 0; #X connect 2 0 8 0; #X connect 3 0 16 0; #X connect 4 0 23 0; #X connect 5 0 27 0; #X connect 6 0 20 0; #X connect 7 0 24 0; #X connect 8 0 6 0; #X connect 8 1 7 0; #X connect 9 0 3 1; #X connect 9 1 10 0; #X connect 9 2 11 0; #X connect 10 0 18 1; #X connect 10 1 19 1; #X connect 11 0 13 1; #X connect 11 1 12 1; #X connect 13 0 19 0; #X connect 14 0 13 2; #X connect 14 1 12 2; #X connect 15 0 3 2; #X connect 15 1 14 0; #X connect 16 0 1 0; #X connect 16 1 17 0; #X connect 17 0 18 0; #X connect 18 0 13 0; #X connect 19 0 12 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 22 0 23 0; #X connect 23 0 9 0; #X connect 24 0 25 0; #X connect 24 1 27 1; #X connect 25 0 26 0; #X connect 26 0 27 0; #X connect 27 0 15 0; #X restore 469 494 pd closedcylinder; #X text 346 477 this is a version without the openGL-wrapper; #X text 360 491 it is slower::; #X text 48 21 this is an example of how to use Gem's openGL-wrapper-objects to speed up things; #X connect 0 0 7 0; #X connect 2 0 10 0; #X connect 3 0 11 0; #X connect 5 1 21 0; #X connect 6 0 16 0; #X connect 7 0 1 0; #X
Re: [PD] spread Gem-computation over several dsp-cycles (?)
cyrille henry a écrit : hello, anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card. btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille don't forget you can optimized your patch with GEMglGenList / GEMglNewList etc in order to create a display list so that you patch could resume in : repeat 1000 [ GEMglCallList cyrille Roman Haefeli a écrit : hello cyrille thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed. putting this in the render chain works and gives the expected result: [t b b a] | // [any ] but this makes pd/gem completely stuck: [t b b a] | | | | [del 10] | | // [any ] as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution. 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. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done. how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize? roman On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote: to store gem pointer, you can use the any object. but if you want to render primitive when gem does not expect it (like sprend in the 50ms as you explain), you can't expect it to render anything. in the better case, it will not crash. cyrille Roman Haefeli a écrit : hi all it's a known trick to use [repeat] from zexy in a gem render chain to produce funny effects and to multiply the rendering of the attached objects. the problem i have here, is that i use a [repeat] with a very high iteration number (1000). after the [repeat 1000] some stuff is calculated and read from tables and then sent to gem-objects on each iteration. this works well, but on each render-cycle i get a short dropout. i use the default framerate of 20, that should make 50ms per frame, but with [realtime] i measure around 70ms. i could live with that, but i thought that this could be optimized. it's the concept of pd, that when a message is triggered, it gets completely processed in the same dsp-cycle. but when working with gem, this makes absolutely no sense, since the time between each render cycle is much higher (50ms in my case). that's why i wanted to build a slow repeat with [until] and [list], so that i can spread the 1000 iterations over the whole 50ms. unfortunately it is not possible to store a gem pointer with [list]. when i connect a [gemhead] to the right inlet of a [list] and turn rendering on, pd immediately crashes (at least here, i didn't test on other computers). i tried also to bang 'manually' the [gemhead] instead, but then the iterations don't have any effect (no objects are multiplied). is there any way to store a gem pointer? or is there another way of producing slow repeats of a gem pointer? any help appreciated! roman ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?)
hi IOhannes On Wed, 2007-02-28 at 14:46 +0100, IOhannes m zmoelnig wrote: Roman Haefeli wrote: hello cyrille thank you. [any] was what i was looking for. it can store a gem-pointer. but as you mentioned it doesn't work when delayed. putting this in the render chain works and gives the expected result: [t b b a] | // [any ] but this makes pd/gem completely stuck: [t b b a] | | | | [del 10] | | // [any ] as you said, this is obviously the wrong approach. but my problem persists. unfortunately i can't see the design of gem behind the objects. so i wonder if there is still a solution. this is not a question of the design of Gem but of openGL. for most objects (but the pix_ stuff), Gem directly communicates with the underlying openGL-infrastructure. for this to work, one must get hold of the openGL context. using delayed gem-messages, the openGL-context will most likely be grabbed by another application. 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. the problem i have with my gem patch (and probably other gem-patches have as well) is that during one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33 dsp-cycle there is no work to be done. on the long run i have plans to put the rendering into a separate thread. however, don't expect it too soon. hm... i am bit unsure now. chris clepper said in his previous mail, that gem rendering is not bound to the dsp-ticks. but when you say, that threading would help in this case, does that mean, the rendering _is_ bound to the dsp-ticks? do i understand something wrong? how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come along with that? are there other ways to optimize? 2 ways: - use longer audio buffers (e.g. 100ms) for some reason, it doesn't help here. it's not the audio i care about, but that timing is lost and the desired frameperiod grows to 70ms. and what is most surprising here, sometimes i close the patch i am working on and open it again and start rendering and for some unexplainable reason: frameperiod is 50ms. this is with the same patch with the same gem-objects in gemwin. - use 2 instances of pd: one for audio and one for video; one of them (or a third one) is master and controls the rest. yeah, when i want to do audio at the same time, i'll do that. roman ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?)
On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote: btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). hey, soo nice pictures. do you have also a movie of them? wonderfull to see what is possible with gem. roman patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?)
Roman Haefeli a écrit : On Wed, 2007-02-28 at 17:15 +0100, cyrille henry wrote: btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). hey, soo nice pictures. do you have also a movie of them? no, they did not really move. thanks c wonderfull to see what is possible with gem. roman patch to make this is almost the LS demo patch i send to this list few time ago. ok, i don't make sound with those, but a good graphic card really improve processing speed. cyrille ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?)
On Wed, Feb 28, 2007 at 05:15:32PM +0100, cyrille henry wrote: anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card. btw. http://nusmuk.free.fr/fleur/ some of those got more than 200 000 cube, (render at 1 fps for the slower). Awesome!!! Chris. --- [EMAIL PROTECTED] http://mccormick.cx ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])
as always: i forgot the attachment On Wed, 2007-02-28 at 23:24 +0100, Roman Haefeli wrote: On Wed, 2007-02-28 at 07:14 -0600, chris clepper wrote: On 2/28/07, Roman Haefeli [EMAIL PROTECTED] 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 frhe Vogel fngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list #N canvas 394 19 736 552 10; #X obj 26 123 gemwin; #X obj 26 42 sel 0 1; #X msg 26 95 0 \, destroy; #X obj 26 19 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1 ; #X obj 216 102 gemhead; #X obj 216 152 translateXYZ 1 1 0; #X obj 23 152 gemhead; #X obj 23 210 world_light; #X msg 48 66 perspec -1 1 -1 1 2 2000 \, lighting 1 \, create \, 1 ; #X obj 23 177 rotateXYZ 30 -54 0; #N canvas 1115 145 249 311 measure_realtime 0; #X obj 39 40 t b b; #X obj 39 256 outlet; #X obj 39 16 gemhead; #X obj 39 141 f; #X obj 39 186 +; #X obj 39 163 * 9; #X obj 39 209 * 0.1; #X obj 39 118 t b f; #X text 97 155 smooth it a bit; #X obj 39 62 realtime; #X connect 0 0 9 0; #X connect 0 1 9 1; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 6 0; #X connect 5 0 4 0; #X connect 6 0 3 1; #X connect 6 0 1 0; #X connect 7 0 3 0; #X connect 7 1 4 1; #X connect 9 0 7 0; #X restore 198 339 pd measure_realtime; #X floatatom 198 368 5 0 0 0 - - -; #X obj 217 236 rotateXYZ 1 0 0; #X text 247 370 - check if it goes higher than 50ms; #X obj 217 298 cube 0.02; #X obj 217 211 translateXYZ -0.001 0 0; #X obj 217 263 translateXYZ 0 0 0.02; #X obj 31 249 bang~; #X obj 31 276 t b b; #X obj 31 300 realtime; #X obj 31 326 t b f; #X obj 31 350 f; #X obj 58 351 + 1; #X obj 31 379 pack f f; #X obj 99 245 gemhead; #X obj 99 270 b; #X obj 99 293 0; #X floatatom 31 434 0 0 0 0 - - -; #X floatatom 85 435 0 0 0 0 - - -; #X floatatom 127 435 0 0 0 0 - - -; #X floatatom 171 436 0 0 0 0 - - -; #X floatatom 214 436 0 0 0 0 - - -; #X floatatom 255 437 0 0 0 0 - - -; #X text 37 457 1; #X text 94 458 2; #X text 135 458 3; #X text 180 459 4; #X text 225 459 5; #X obj 31 403 route 0 1 2 3 4 5; #X text 262 459 6; #X text 28 477 realtime measured lenght of the nth dsp-cycle after the [gemhead] starts rendering.; #X obj 216 129 rotateXYZ 0 0 90; #X obj 216 187 repeat 2000; #X text 55 17 - rendering on/off; #X floatatom 380 146 5 0 0 0 - - -; #X text 425 143 - try different 'loads'; #X connect 1 0 2 0; #X connect 1 1 8 0; #X connect 2 0 0 0; #X connect 3 0 1 0; #X connect 4 0 41 0; #X connect 5 0 42 0; #X connect 6 0 9 0; #X connect 8 0 0 0; #X connect 9 0 7 0; #X connect 10 0 11 0; #X connect 12 0 16 0; #X connect 15 0 12 0; #X connect 16 0 14 0; #X connect 17 0 18 0; #X connect 18 0 19 0; #X connect 18 1 19 1; #X connect 19 0 20 0; #X connect 20 0 21 0; #X connect 20 1 23 1; #X connect 21 0 22 0; #X connect 21 0 23 0; #X connect 22 0 21 1; #X connect 23 0 38 0; #X connect 24 0 25 0; #X connect 25 0 26 0; #X connect 26 0 21 1; #X connect 38 0 27 0; #X connect 38 1 28 0; #X connect 38 2 29 0; #X connect 38 3 30 0; #X connect 38 4 31 0; #X connect 38 5 32 0; #X connect 41 0 5 0; #X connect 42 0 15 0; #X connect 44 0 42 1; ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
