hello, i'm curently working on a mac pro quad (and HCS pd39-2-extended RC1). i've got 2 problems.
1 st : reading movie does create a new thread as i can see in activity monitor, but the cpu used by pd + reading movie does never exeed 100% (i.e 25% of the all CPUs). is there a solution to improve this? i would like to be able to play many movie using 4 core of this computer.
i also have a problem with pix_coloralpha. it look like pix_coloralpha does not change the alpha chanel of the movie. i test the same patch / same movie on linux where everything is working ok. is there something that i should know to use this on osX?
thanks Cyrille
On 4/17/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello, i'm curently working on a mac pro quad (and HCS pd39-2-extended RC1). i've got 2 problems.
1 st : reading movie does create a new thread as i can see in activity monitor, but the cpu used by pd + reading movie does never exeed 100% (i.e 25% of the all CPUs). is there a solution to improve this? i would like to be able to play many movie using 4 core of this computer.
Depends on what codec you use. All of the DV codecs use multiple threads to decompress and so does Apple Intermediate Codec.
i also have a problem with pix_coloralpha. it look like pix_coloralpha
does not change the alpha chanel of the movie. i test the same patch / same movie on linux where everything is working ok. is there something that i should know to use this on osX?
The default colorspace on OSX is YUV so there is no alpha. You can send a 'colorspace rgb' message to pix_film which will slow everything down a lot or use a shader which will be fast.
thanks
Cyrille
hello,
chris clepper a écrit :
On 4/17/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello, i'm curently working on a mac pro quad (and HCS pd39-2-extended RC1). i've got 2 problems.
1 st : reading movie does create a new thread as i can see in activity monitor, but the cpu used by pd + reading movie does never exeed 100% (i.e 25% of the all CPUs). is there a solution to improve this? i would like to be able to play many movie using 4 core of this computer.
Depends on what codec you use. All of the DV codecs use multiple threads to decompress and so does Apple Intermediate Codec.
i made a test patch that should decompress and display about 10 DV quality movie. the activity monitor says that pd use more than 30 threads. BUT, pd use 25% of every core, and GEM display 3 images /s. there is a problem somwhere, but i can't find what.
i also have a problem with pix_coloralpha. it look like pix_coloralpha
does not change the alpha chanel of the movie. i test the same patch / same movie on linux where everything is working ok. is there something that i should know to use this on osX?
The default colorspace on OSX is YUV so there is no alpha. You can send a 'colorspace rgb' message to pix_film which will slow everything down a lot or use a shader which will be fast.
I tried openning the file with the message [open test.mov RGBA< i also try sendind a message colorspace RGBA and finally using the pix_rgba object with no success.
i just realize that the pix_coloralpha help file does not word on this computer.
A shader will be the solution.
thanks Cyrille
thanks
Cyrille
On 4/18/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Depends on what codec you use. All of the DV codecs use multiple threads to decompress and so does Apple Intermediate Codec.
i made a test patch that should decompress and display about 10 DV quality movie. the activity monitor says that pd use more than 30 threads. BUT, pd use 25% of every core, and GEM display 3 images /s. there is a problem somwhere, but i can't find what.
Which version of GEM? There is a problem with the QT DV component looping the audio track that will do exactly what you describe. I disabled the first audio track in any movie file in the GEM code but your clip might have more than one audio track.
Also at a certain point you will hit the limit of what the machine will do. The Mac 'Pro' isn't as fast as Apple's marketing wants it to be. The Intel chips have serious memory bus speed problems and the OSX kernel likes to destroy any CPU affinity.
If you do not need any pix_ objects for processing then use pix_movie. That will improve performance quite a bit since it uses the fastest texturing path.
hello,
chris clepper a écrit :
On 4/18/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
Depends on what codec you use. All of the DV codecs use multiple threads to decompress and so does Apple Intermediate Codec.
i made a test patch that should decompress and display about 10 DV quality movie. the activity monitor says that pd use more than 30 threads. BUT, pd use 25% of every core, and GEM display 3 images /s. there is a problem somwhere, but i can't find what.
Which version of GEM?
0.91-cvs, april 14 2007, from HCS installer
There is a problem with the QT DV component looping the audio track that will do exactly what you describe. I disabled the first audio track in any movie file in the GEM code but your clip might have more than one audio track.
i'm quite sure there is not audio track.
Also at a certain point you will hit the limit of what the machine will do. The Mac 'Pro' isn't as fast as Apple's marketing wants it to be. The Intel chips have serious memory bus speed problems and the OSX kernel likes to destroy any CPU affinity.
hum. i don't need the fastest computer of the world, but i just want to use the 4 cores!
If you do not need any pix_ objects for processing then use pix_movie. That will improve performance quite a bit since it uses the fastest texturing path.
yes, that does improve performances. i hope using pix_movie + shader will be ok.
thanks a lot Cyrille
On 4/18/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
yes, that does improve performances. i hope using pix_movie + shader will be ok.
So you can play 10 DV clips now? The shaders will work but performance can still be a problem. Pixel shaders are far from 'free' operations. A moderately complex shader applied to a few quads stretched to 1280x1024 or higher can be slow. The more pixels your texture uses on screen the more work the shader has to do. It is not fixed to the size of the texture you upload.
hello,
chris clepper a écrit :
On 4/18/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
yes, that does improve performances. i hope using pix_movie + shader will be ok.
working with shader make strange things with texturing mode : when i start a patch, i have to send a mode 0 to pix_texture in order to see anything. so, i can't work with pix_movie instead of pix_film when i use shader.
So you can play 10 DV clips now?
regarding the codec, i can have from 2 to 8 DV film on the same time (with shader / pix_film). 8 is not that bad, i think it will be ok.
The shaders will work but performance can still be a problem. Pixel shaders are far from 'free' operations. A moderately complex shader applied to a few quads stretched to 1280x1024 or higher can be slow. The more pixels your texture uses on screen the more work the shader has to do. It is not fixed to the size of the texture you upload.
yes, this is obvius regarding the way pixel shader work. but i did not do complex operation (removing the sky from movies of clouds). (in fact, there is less computing in the processing i'm doing than computing complex lighting on a white square).
thanks a lot for your help.
cyrille
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 4/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
working with shader make strange things with texturing mode : when i start a patch, i have to send a mode 0 to pix_texture in order to see anything. so, i can't work with pix_movie instead of pix_film when i use shader.
Oh. You need to write shaders for rectangle textures. For ARB change the 2D to RECT in your TEX command. GLSL needs a samplerRECT instead of sampler2D and so on.
So you can play 10 DV clips now?
regarding the codec, i can have from 2 to 8 DV film on the same time (with shader / pix_film). 8 is not that bad, i think it will be ok.
yes, this is obvius regarding the way pixel shader work. but i did not do complex operation (removing the sky from movies of clouds). (in fact, there is less computing in the processing i'm doing than computing complex lighting on a white square).
What GPU does the machine have? The Nvidia 7300 cannot handle a lot of pixel shaders but the ATI x1900 can do quite a bit.
chris clepper a écrit :
On 4/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
working with shader make strange things with texturing mode : when i start a patch, i have to send a mode 0 to pix_texture in order to see anything. so, i can't work with pix_movie instead of pix_film when i use shader.
Oh. You need to write shaders for rectangle textures. For ARB change the 2D to RECT in your TEX command. GLSL needs a samplerRECT instead of sampler2D and so on.
So you can play 10 DV clips now?
with RECT texturing mode and pix_movie, thing are lot's faster. multiphreading works better to. I can use about 25 DV clip at 25fps, using about 250% cpu. everything work now as expected....
ok, macpro are not so bad after all :-)
thanks a lot
cyrille
regarding the codec, i can have from 2 to 8 DV film on the same time (with shader / pix_film). 8 is not that bad, i think it will be ok.
yes, this is obvius regarding the way pixel shader work. but i did not do complex operation (removing the sky from movies of clouds). (in fact, there is less computing in the processing i'm doing than computing complex lighting on a white square).
What GPU does the machine have? The Nvidia 7300 cannot handle a lot of pixel shaders but the ATI x1900 can do quite a bit.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 4/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
with RECT texturing mode and pix_movie, thing are lot's faster. multiphreading works better to. I can use about 25 DV clip at 25fps, using about 250% cpu. everything work now as expected....
ok, macpro are not so bad after all :-)
25 is a more than I have gotten running so far - maybe PAL is more efficent than NTSC. The reason pix_movie is so much faster is that it uses the most efficient texturing path by default. The standard pix_texture code waits for the texture upload to the GPU before continuing which stalls all of the rendering. You can send a 'client_storage 1' message to pix_texture to try and get that object to use the more efficient code but it doesn't always work - especially on the MacPro with ATI.
hello,
i don't know what changed, but i am now able to use RECT texturing with shader under linux. i don't have time yet to test if my patch will get a performance boost like this, but i hope i'll be able to use multiple texturing now.
that will make my life easier.
cyrille
chris clepper a écrit :
On 4/19/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
with RECT texturing mode and pix_movie, thing are lot's faster. multiphreading works better to. I can use about 25 DV clip at 25fps, using about 250% cpu. everything work now as expected....
ok, macpro are not so bad after all :-)
25 is a more than I have gotten running so far - maybe PAL is more efficent than NTSC. The reason pix_movie is so much faster is that it uses the most efficient texturing path by default. The standard pix_texture code waits for the texture upload to the GPU before continuing which stalls all of the rendering. You can send a 'client_storage 1' message to pix_texture to try and get that object to use the more efficient code but it doesn't always work - especially on the MacPro with ATI.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Rectangle texturing and shaders work on all three platforms. It does not provide the same performance gain on Windows that it does on OSX though. I have not tested Linux recently.
On 4/20/07, cyrille henry cyrille.henry@la-kitchen.fr wrote:
hello,
i don't know what changed, but i am now able to use RECT texturing with shader under linux. i don't have time yet to test if my patch will get a performance boost like this, but i hope i'll be able to use multiple texturing now.
that will make my life easier.
cyrille
-
chris clepper -
cyrille henry