Hello,
I'm trying to load 300 very small textures with the same abstraction (dynamic patching) under Ubuntu 9.04 on Pd-ext 0.41.4 with GEM 0.92.CVS with GeForce 9700M GTS. But it doesn't work. Pd become very slow and CPU is used at 197% by Pd. All works fine on MacOSX.4.11 Pd-ext 0.40.3 and GEM 0.91.1 'tigital' with GeForce 7300 GT.
I have something like that :
[300( | [until] | [f ]X[+ 1] | [obj $1 $1 absForTexture $1] | [s pd-mesTextures]
and my abstraction 'absForTexture' :
[r gh] [initbang] | | | [0 ( | / [sel $1] | / | / | / |/ [gemhead] | [pix_image images/monimage$1.jpg] | [pix_texture] | [s nbtxt]
Any idea about this problem ? Thanx. ++
Jack
Sorry this not : [obj $1 $1 absForTexture $1] but [obj $1 $1 absForTexture $1( ++
Jack
Le 24 juin 09 à 01:31, Jack a écrit :
Hello,
I'm trying to load 300 very small textures with the same abstraction (dynamic patching) under Ubuntu 9.04 on Pd-ext 0.41.4 with GEM 0.92.CVS with GeForce 9700M GTS. But it doesn't work. Pd become very slow and CPU is used at 197% by Pd. All works fine on MacOSX.4.11 Pd-ext 0.40.3 and GEM 0.91.1 'tigital' with GeForce 7300 GT.
I have something like that :
[300( | [until] | [f ]X[+ 1] | [obj $1 $1 absForTexture $1] | [s pd-mesTextures]
and my abstraction 'absForTexture' :
[r gh] [initbang] | | | [0 ( | / [sel $1] | / | / | / |/ [gemhead] | [pix_image images/monimage$1.jpg] | [pix_texture] | [s nbtxt]
Any idea about this problem ? Thanx. ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
what is the size of the memory on your GPU? does the 300 uncompressed images fit in there? otherwise, it will became very slow.
you can see if mem size is the problem if everything is normal when loading 250 image and it became slaw if you add 1 more images...
c
Jack a écrit :
Hello,
I'm trying to load 300 very small textures with the same abstraction (dynamic patching) under Ubuntu 9.04 on Pd-ext 0.41.4 with GEM 0.92.CVS with GeForce 9700M GTS. But it doesn't work. Pd become very slow and CPU is used at 197% by Pd. All works fine on MacOSX.4.11 Pd-ext 0.40.3 and GEM 0.91.1 'tigital' with GeForce 7300 GT.
I have something like that :
[300( | [until] | [f ]X[+ 1] | [obj $1 $1 absForTexture $1] | [s pd-mesTextures]
and my abstraction 'absForTexture' :
[r gh] [initbang] | | | [0 ( | / [sel $1] | / | / | / |/ [gemhead] | [pix_image images/monimage$1.jpg] | [pix_texture] | [s nbtxt]
Any idea about this problem ? Thanx. ++
Jack
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
There is 512 MB of memory on the GPU. All informations are here : http://www.notebookcheck.net/NVIDIA-GeForce-9700M-GTS.9899.0.html
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB). Even with 100 images it is slow (but it seems good with 50 images). I needn't to create my Gemwin and turn on rendering to have this problem. I give you the main patch and the abstraction here. Thanx for the help. ++
Jack
Le 24 juin 09 à 09:07, cyrille henry a écrit :
what is the size of the memory on your GPU? does the 300 uncompressed images fit in there? otherwise, it will became very slow.
you can see if mem size is the problem if everything is normal when loading 250 image and it became slaw if you add 1 more images...
c
Jack a écrit :
Hello, I'm trying to load 300 very small textures with the same abstraction (dynamic patching) under Ubuntu 9.04 on Pd-ext 0.41.4 with GEM 0.92.CVS with GeForce 9700M GTS. But it doesn't work. Pd become very slow and CPU is used at 197% by Pd. All works fine on MacOSX.4.11 Pd-ext 0.40.3 and GEM 0.91.1 'tigital' with GeForce 7300 GT. I have something like that : [300( | [until] | [f ]X[+ 1] | [obj $1 $1 absForTexture $1] | [s pd-mesTextures] and my abstraction 'absForTexture' : [r gh] [initbang] | | | [0 ( | / [sel $1] | / | / | / |/ [gemhead] | [pix_image images/monimage$1.jpg] | [pix_texture] | [s nbtxt] Any idea about this problem ? Thanx. ++ Jack _______________________________________________ GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Jack wrote:
There is 512 MB of memory on the GPU. All informations are here : http://www.notebookcheck.net/NVIDIA-GeForce-9700M-GTS.9899.0.html
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB). Even with 100 images it is slow (but it seems good with 50 images). I needn't to create my Gemwin and turn on rendering to have this problem. I give you the main patch and the abstraction here. Thanx for the help.
hmm, i don't have any problems here with loading 300 images (and i replaced monimage*.jpg with the famous fractal.JPG which is 256x256 pixels)
however, i do have a "GeForce 7800 GTX".
anyhow, what comes to my mind is, that on linux, images are usually loaded in a separate thread (one thread for each [pix_image]!) - thus you will create 300 threads (which is not that much; but the only thing i can think of). you can turn off the threaded loading by sending a [thread 0( message to [pix_image] (e.g. at [initbang] time) you probably have to load the image _after_ you have turned off threaded-loading, so use something like
[i $1] | [thread 0, open images/monimage$1.jpg(
gfmasdr IOhannes
Outstanding ! It is working ! Thanx a lot Iohannes. ++
Jack
Le 24 juin 09 à 15:43, IOhannes m zmoelnig a écrit :
Jack wrote:
There is 512 MB of memory on the GPU. All informations are here : http://www.notebookcheck.net/NVIDIA-GeForce-9700M-GTS.9899.0.html However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB). Even with 100 images it is slow (but it seems good with 50 images). I needn't to create my Gemwin and turn on rendering to have this problem. I give you the main patch and the abstraction here. Thanx for the help.
hmm, i don't have any problems here with loading 300 images (and i replaced monimage*.jpg with the famous fractal.JPG which is 256x256 pixels)
however, i do have a "GeForce 7800 GTX".
anyhow, what comes to my mind is, that on linux, images are usually loaded in a separate thread (one thread for each [pix_image]!) - thus you will create 300 threads (which is not that much; but the only thing i can think of). you can turn off the threaded loading by sending a [thread 0( message to [pix_image] (e.g. at [initbang] time) you probably have to load the image _after_ you have turned off threaded-loading, so use something like
[i $1] | [thread 0, open images/monimage$1.jpg(
gfmasdr IOhannes
IOhannes m zmoelnig a écrit :
anyhow, what comes to my mind is, that on linux, images are usually loaded in a separate thread (one thread for each [pix_image]!) - thus you will create 300 threads (which is not that much; but the only thing i can think of). you can turn off the threaded loading by sending a [thread 0( message to [pix_image] (e.g. at [initbang] time)
why did the thread did not stop once the image is loaded? do you really need initbang, or loadbang is ok? it look like a nice feature to document on the help file...
c
you probably have to load the image _after_ you have turned off threaded-loading, so use something like
[i $1] | [thread 0, open images/monimage$1.jpg(
gfmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
anyhow, what comes to my mind is, that on linux, images are usually loaded in a separate thread (one thread for each [pix_image]!) - thus you will create 300 threads (which is not that much; but the only thing i can think of). you can turn off the threaded loading by sending a [thread 0( message to [pix_image] (e.g. at [initbang] time)
why did the thread did not stop once the image is loaded?
good question. i guess it's there to minimize the overhead of thread-creation each time you load a new image. another option would be to have a single thread running all the time and serving all [pix_image]s; but image the synch-problems...
do you really need initbang, or loadbang is ok?
[loadbang] won't work here as the patches are created dynamically. a better solution (portable to Pd-vanilla) would be to use [r initbang] and just send a bang to initbang when creation has finished.
it look like a nice feature to document on the help file...
yeah, i gonna add the [thread $1( message to the docs.
fgadsmr IOhannes
IOhannes m zmoelnig a écrit :
cyrille henry wrote:
IOhannes m zmoelnig a écrit :
anyhow, what comes to my mind is, that on linux, images are usually loaded in a separate thread (one thread for each [pix_image]!) - thus you will create 300 threads (which is not that much; but the only thing i can think of). you can turn off the threaded loading by sending a [thread 0( message to [pix_image] (e.g. at [initbang] time)
why did the thread did not stop once the image is loaded?
good question. i guess it's there to minimize the overhead of thread-creation each time you load a new image. another option would be to have a single thread running all the time and serving all [pix_image]s; but image the synch-problems...
do you really need initbang, or loadbang is ok?
[loadbang] won't work here as the patches are created dynamically.
oups, yes, right.
a better solution (portable to Pd-vanilla) would be to use [r initbang] and just send a bang to initbang when creation has finished.
or send a loadbang message to the abstraction...
it look like a nice feature to document on the help file...
yeah, i gonna add the [thread $1( message to the docs.
ok, thanks
c
fgadsmr IOhannes
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
Thanx Chris, but the solution given by Iohannes seems to work perfectly. However, is it better for performance to give to an image a width multiple of 16 in any cases or not ? I use the last NVidia driver 180.44 on Ubuntu 9.04. ++
Jack
Le 24 juin 09 à 16:32, chris clepper a écrit :
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
Hello Chris,
Excuse me to come back on this question. But can you help me about width image size and drivers ? Do you know if there is optimization with the NVidia driver 180.44 and images with size multiple of 16 px in width ? If the answer is yes, i have to resize my images because i use 768 textures with different size at 4 fps (enough for me but if i can optimize, why not ;). (I use GeForce 9700M GTS on Ubuntu 9.04). Thanx. ++
Jack
Le 24 juin 09 à 16:55, Jack a écrit :
Thanx Chris, but the solution given by Iohannes seems to work perfectly. However, is it better for performance to give to an image a width multiple of 16 in any cases or not ? I use the last NVidia driver 180.44 on Ubuntu 9.04. ++
Jack
Le 24 juin 09 à 16:32, chris clepper a écrit :
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
You are just going to have to test it. On OSX video textures that are multiples of 16 have been twice as efficient or more.
On Thu, Jun 25, 2009 at 11:10 AM, Jack jack@rybn.org wrote:
Hello Chris, Excuse me to come back on this question. But can you help me about width image size and drivers ? Do you know if there is optimization with the NVidia driver 180.44 and images with size multiple of 16 px in width ? If the answer is yes, i have to resize my images because i use 768 textures with different size at 4 fps (enough for me but if i can optimize, why not ;). (I use GeForce 9700M GTS on Ubuntu 9.04). Thanx. ++
Jack
Le 24 juin 09 à 16:55, Jack a écrit :
Thanx Chris, but the solution given by Iohannes seems to work perfectly.However, is it better for performance to give to an image a width multiple of 16 in any cases or not ? I use the last NVidia driver 180.44 on Ubuntu 9.04. ++
Jack
Le 24 juin 09 à 16:32, chris clepper a écrit :
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Incredible ! I will test it now ! Thanx. ++
Jack
Le 25 juin 09 à 17:14, chris clepper a écrit :
You are just going to have to test it. On OSX video textures that are multiples of 16 have been twice as efficient or more.
On Thu, Jun 25, 2009 at 11:10 AM, Jack jack@rybn.org wrote: Hello Chris,
Excuse me to come back on this question. But can you help me about width image size and drivers ? Do you know if there is optimization with the NVidia driver 180.44 and images with size multiple of 16 px in width ? If the answer is yes, i have to resize my images because i use 768 textures with different size at 4 fps (enough for me but if i can optimize, why not ;). (I use GeForce 9700M GTS on Ubuntu 9.04). Thanx. ++
Jack
Le 24 juin 09 à 16:55, Jack a écrit :
Thanx Chris, but the solution given by Iohannes seems to work perfectly. However, is it better for performance to give to an image a width multiple of 16 in any cases or not ? I use the last NVidia driver 180.44 on Ubuntu 9.04. ++
Jack
Le 24 juin 09 à 16:32, chris clepper a écrit :
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
I resize all my images with ImageMagick to 16x16 px to see, but no really change about performances :( So there is no really optimization with NVidia driver 180.44 on GeForce 9700M GTS and Ubuntu 9.04. ++
Jack
Le 25 juin 09 à 17:18, Jack a écrit :
Incredible ! I will test it now ! Thanx. ++
Jack
Le 25 juin 09 à 17:14, chris clepper a écrit :
You are just going to have to test it. On OSX video textures that are multiples of 16 have been twice as efficient or more.
On Thu, Jun 25, 2009 at 11:10 AM, Jack jack@rybn.org wrote: Hello Chris,
Excuse me to come back on this question. But can you help me about width image size and drivers ? Do you know if there is optimization with the NVidia driver 180.44 and images with size multiple of 16 px in width ? If the answer is yes, i have to resize my images because i use 768 textures with different size at 4 fps (enough for me but if i can optimize, why not ;). (I use GeForce 9700M GTS on Ubuntu 9.04). Thanx. ++
Jack
Le 24 juin 09 à 16:55, Jack a écrit :
Thanx Chris, but the solution given by Iohannes seems to work perfectly. However, is it better for performance to give to an image a width multiple of 16 in any cases or not ? I use the last NVidia driver 180.44 on Ubuntu 9.04. ++
Jack
Le 24 juin 09 à 16:32, chris clepper a écrit :
On Wed, Jun 24, 2009 at 8:53 AM, Jack jack@rybn.org wrote:
However, there is something very strange if it's about memory because on my MacPro 2x2.66 GHz Dual-Core Intel Xeon, i have only 256 MB on the GPU and all works fine on it (only 2 fps but it is not so slow). The size of the images are between 127x108 and 72x123 pixels (so the total size at 24bit is near 12 MB ! : 127x108x3x300/1048576 = 11.77 MB).
Most of the drivers have optimizations for images that are a multiple of 16 in width, so maybe try using 128 pixel wide images and see if that helps.
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
Jack