I'm working with a high-powered machine but I'm running into a bottleneck with Gem. I'm running at 20fps and at times was intending to have as many as 200+ lines and spheres on a 1024x768 screen. At around 60 lines/spheres I'm already at 50% CPU. I know the problem is Gem because if I stop rendering, CPU immediately drops to less than 4%. There's some other manipulations I use periodically too causing another 40%+ of CPU so I'm a far cry from my 200+ intention while saturating my computational limits. If I turn lighting off, BTW, I already gain 10% CPU back (not an option I want to explore.)
I'm not sure what to do and was even considering breaking the rendering into independent screens (this machine has 8 cores), then using pix_share to recombine them in a "master" instance. I'd have to use pix_snap to capture each of the Gem windows in each of the processes, and each one draws about 40% CPU when capturing a 1024x768 buffer at 20 fps so besides creating a headache for myself this is going to be a lot of CPU overhead. I also don't know how the graphics card is fitting into all of this, if it would become a bottleneck at some point, how to tell, etc. What's the "top" command for a graphics card? :-)
These lines and spheres are nothing special, btw. No texturing, just translates, colors, and alpha. the lines are made with curves of 2 points each.
Is there some trick or some area of programming or using the graphics card I need to be considering? Any thoughts/advice would be appreciated. It's strange --- I don't think I'm seeing performance on this machine much better than on my not-so-special laptop.
This machine has Nvidia GeForce GTX 460, Ubuntu 10.10 32 bit, Pd-extended 0.42-5 binary from the Pure Data site, Intel i7 3Ghz. I'm using Nvidia proprietary driver 290.19.06.
When I say stuff like "40% CPU" I mean for a single core. So in theory this machine has 800% CPU limit in my nomenclature. But since an instance of Pd/Gem runs on only a single core, I have a limit of 100% for any single Pd/Gem instance (as most of you already know I'm sure.)
-John
P.S. I'm loving working with Gem and pmpd these days. Awesome stuff, guys! :-)
hello,
- try using a display list to render a sphere, so that every point don't have to be send for every sphere.
see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
gemhead are slow. i usually have better result using 1 gemhead and 200 separator, or 200 gemlist, than using 200 gemhead.
try to put somewhere :
[gemhead 1] [GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE GL_FALSE]
it help a lot on my computer (GT 425M), but i don't know on other computer. could you try and tell me the performance improvement? (you may have to reverse some light to have close lighting result).
don't forget to check that you CPU run fullspeed. (sometimes pd use more than 100% cpu, but the cpu monitor fail to detect that and the cpu still run at low speed)
start pd -noaudio if it is an option.
you can separate the physical model and the other calculation in a separate pd instance than Gem. using pd~. This may help
well, i think all of this should be enough to draw 10 time more spheres that what you need, at a good fps.
Cyrille
Le 09/03/2011 02:16, John Harrison a écrit :
I'm working with a high-powered machine but I'm running into a bottleneck with Gem. I'm running at 20fps and at times was intending to have as many as 200+ lines and spheres on a 1024x768 screen. At around 60 lines/spheres I'm already at 50% CPU. I know the problem is Gem because if I stop rendering, CPU immediately drops to less than 4%. There's some other manipulations I use periodically too causing another 40%+ of CPU so I'm a far cry from my 200+ intention while saturating my computational limits. If I turn lighting off, BTW, I already gain 10% CPU back (not an option I want to explore.)
I'm not sure what to do and was even considering breaking the rendering into independent screens (this machine has 8 cores), then using pix_share to recombine them in a "master" instance. I'd have to use pix_snap to capture each of the Gem windows in each of the processes, and each one draws about 40% CPU when capturing a 1024x768 buffer at 20 fps so besides creating a headache for myself this is going to be a lot of CPU overhead. I also don't know how the graphics card is fitting into all of this, if it would become a bottleneck at some point, how to tell, etc. What's the "top" command for a graphics card? :-)
These lines and spheres are nothing special, btw. No texturing, just translates, colors, and alpha. the lines are made with curves of 2 points each.
Is there some trick or some area of programming or using the graphics card I need to be considering? Any thoughts/advice would be appreciated. It's strange --- I don't think I'm seeing performance on this machine much better than on my not-so-special laptop.
This machine has Nvidia GeForce GTX 460, Ubuntu 10.10 32 bit, Pd-extended 0.42-5 binary from the Pure Data site, Intel i7 3Ghz. I'm using Nvidia proprietary driver 290.19.06.
When I say stuff like "40% CPU" I mean for a single core. So in theory this machine has 800% CPU limit in my nomenclature. But since an instance of Pd/Gem runs on only a single core, I have a limit of 100% for any single Pd/Gem instance (as most of you already know I'm sure.)
-John
P.S. I'm loving working with Gem and pmpd these days. Awesome stuff, guys! :-)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
thanks for these suggestions. Here's how it's going so far:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry ch@chnry.net wrote:
hello,
- try using a display list to render a sphere, so that every point don't
have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
- gemhead are slow. i usually have better result using 1 gemhead and 200
separator, or 200 gemlist, than using 200 gemhead.
It actually performed marginally slower with 1 gemhead and 200 sep and also slower with 200 gemlist
- try to put somewhere :
[gemhead 1] [GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE GL_FALSE]
it help a lot on my computer (GT 425M), but i don't know on other computer. could you try and tell me the performance improvement? (you may have to reverse some light to have close lighting result).
From your earlier email thread on this list, I already tried that before. No
difference.
- don't forget to check that you CPU run fullspeed. (sometimes pd use more
than 100% cpu, but the cpu monitor fail to detect that and the cpu still run at low speed)
yeah it appears that happened, but forcing the CPU to run full speed makes no difference for some reason.
- start pd -noaudio if it is an option.
Already was done.
- you can separate the physical model and the other calculation in a
separate pd instance than Gem. using pd~. This may help
If I turn off rendering, CPU usage with physical model being calculated hovers at about 4%, so this doesn't seem worth the effort. Am I missing something?
Sending [res 2( to curve also made no difference.
well, i think all of this should be enough to draw 10 time more spheres that what you need, at a good fps.
So far my mileage is varying! :-)
Thanks for the help. I guess I'll try the model next.
-John
Cyrille
Le 09/03/2011 02:16, John Harrison a écrit :
I'm working with a high-powered machine but I'm running into a bottleneck with Gem. I'm running at 20fps and at times was intending to have as many as 200+ lines and spheres on a 1024x768 screen. At around 60 lines/spheres I'm already at 50% CPU. I know the problem is Gem because if I stop rendering, CPU immediately drops to less than 4%. There's some other manipulations I use periodically too causing another 40%+ of CPU so I'm a far cry from my 200+ intention while saturating my computational limits. If I turn lighting off, BTW, I already gain 10% CPU back (not an option I want to explore.)
I'm not sure what to do and was even considering breaking the rendering into independent screens (this machine has 8 cores), then using pix_share to recombine them in a "master" instance. I'd have to use pix_snap to capture each of the Gem windows in each of the processes, and each one draws about 40% CPU when capturing a 1024x768 buffer at 20 fps so besides creating a headache for myself this is going to be a lot of CPU overhead. I also don't know how the graphics card is fitting into all of this, if it would become a bottleneck at some point, how to tell, etc. What's the "top" command for a graphics card? :-)
These lines and spheres are nothing special, btw. No texturing, just translates, colors, and alpha. the lines are made with curves of 2 points each.
Is there some trick or some area of programming or using the graphics card I need to be considering? Any thoughts/advice would be appreciated. It's strange --- I don't think I'm seeing performance on this machine much better than on my not-so-special laptop.
This machine has Nvidia GeForce GTX 460, Ubuntu 10.10 32 bit, Pd-extended 0.42-5 binary from the Pure Data site, Intel i7 3Ghz. I'm using Nvidia proprietary driver 290.19.06.
When I say stuff like "40% CPU" I mean for a single core. So in theory this machine has 800% CPU limit in my nomenclature. But since an instance of Pd/Gem runs on only a single core, I have a limit of 100% for any single Pd/Gem instance (as most of you already know I'm sure.)
-John
P.S. I'm loving working with Gem and pmpd these days. Awesome stuff, guys! :-)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 09/03/2011 15:22, John Harrison a écrit :
thanks for these suggestions. Here's how it's going so far:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto:ch@chnry.net> wrote:
hello, - try using a display list to render a sphere, so that every point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single sphere. you have to call it 200 times.
i'm really surprised that noting help. the bottle neck should be somewhere else.
you can send me the patch if you wish, so i can have a look.
cyrille
- gemhead are slow. i usually have better result using 1 gemhead and 200 separator, or 200 gemlist, than using 200 gemhead.It actually performed marginally slower with 1 gemhead and 200 sep and also slower with 200 gemlist
- try to put somewhere : [gemhead 1] [GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE GL_FALSE] it help a lot on my computer (GT 425M), but i don't know on other computer. could you try and tell me the performance improvement? (you may have to reverse some light to have close lighting result).From your earlier email thread on this list, I already tried that before. No difference.
- don't forget to check that you CPU run fullspeed. (sometimes pd use more than 100% cpu, but the cpu monitor fail to detect that and the cpu still run at low speed)yeah it appears that happened, but forcing the CPU to run full speed makes no difference for some reason.
- start pd -noaudio if it is an option.Already was done.
- you can separate the physical model and the other calculation in a separate pd instance than Gem. using pd~. This may helpIf I turn off rendering, CPU usage with physical model being calculated hovers at about 4%, so this doesn't seem worth the effort. Am I missing something?
Sending [res 2( to curve also made no difference.
well, i think all of this should be enough to draw 10 time more spheres that what you need, at a good fps.So far my mileage is varying! :-)
Thanks for the help. I guess I'll try the model next.
-John
Cyrille Le 09/03/2011 02:16, John Harrison a écrit : I'm working with a high-powered machine but I'm running into a bottleneck with Gem. I'm running at 20fps and at times was intending to have as many as 200+ lines and spheres on a 1024x768 screen. At around 60 lines/spheres I'm already at 50% CPU. I know the problem is Gem because if I stop rendering, CPU immediately drops to less than 4%. There's some other manipulations I use periodically too causing another 40%+ of CPU so I'm a far cry from my 200+ intention while saturating my computational limits. If I turn lighting off, BTW, I already gain 10% CPU back (not an option I want to explore.) I'm not sure what to do and was even considering breaking the rendering into independent screens (this machine has 8 cores), then using pix_share to recombine them in a "master" instance. I'd have to use pix_snap to capture each of the Gem windows in each of the processes, and each one draws about 40% CPU when capturing a 1024x768 buffer at 20 fps so besides creating a headache for myself this is going to be a lot of CPU overhead. I also don't know how the graphics card is fitting into all of this, if it would become a bottleneck at some point, how to tell, etc. What's the "top" command for a graphics card? :-) These lines and spheres are nothing special, btw. No texturing, just translates, colors, and alpha. the lines are made with curves of 2 points each. Is there some trick or some area of programming or using the graphics card I need to be considering? Any thoughts/advice would be appreciated. It's strange --- I don't think I'm seeing performance on this machine much better than on my not-so-special laptop. This machine has Nvidia GeForce GTX 460, Ubuntu 10.10 32 bit, Pd-extended 0.42-5 binary from the Pure Data site, Intel i7 3Ghz. I'm using Nvidia proprietary driver 290.19.06. When I say stuff like "40% CPU" I mean for a single core. So in theory this machine has 800% CPU limit in my nomenclature. But since an instance of Pd/Gem runs on only a single core, I have a limit of 100% for any single Pd/Gem instance (as most of you already know I'm sure.) -John P.S. I'm loving working with Gem and pmpd these days. Awesome stuff, guys! :-) _______________________________________________ Pd-list@iem.at <mailto: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
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto: ch@chnry.net> wrote:
hello,
- try using a display list to render a sphere, so that every point
don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single sphere.
you have to call it 200 times.
Ok I'm seeing a huge performance difference between using 200 of [sphere
<size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time.
This list is awesome. Where else could I find help like this? :-)
-John
A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much.
On Wed, Mar 9, 2011 at 10:32 AM, John Harrison johnharrisonwsu@gmail.comwrote:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto: ch@chnry.net> wrote:
hello,
- try using a display list to render a sphere, so that every point
don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single sphere.
you have to call it 200 times.
Ok I'm seeing a huge performance difference between using 200 of [sphere
<size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time.
This list is awesome. Where else could I find help like this? :-)
-John
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Using Cyrille's test patch for speed which he sent into the list a week or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter.
http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj
maybe one with less vertices will help. I can try...
-John
On Wed, Mar 9, 2011 at 9:48 AM, chris clepper cgclepper@gmail.com wrote:
A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much.
On Wed, Mar 9, 2011 at 10:32 AM, John Harrison johnharrisonwsu@gmail.comwrote:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto: ch@chnry.net> wrote:
hello,
- try using a display list to render a sphere, so that every point
don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single sphere.
you have to call it 200 times.
Ok I'm seeing a huge performance difference between using 200 of [sphere
<size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time.
This list is awesome. Where else could I find help like this? :-)
-John
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
here, at 20fps, no lighting, i can draw about 500 model with your sphere.obj. 1000 sphere 30, and about 3500 display list of sphere 30. using an other sphere.obj with about 900 triangles, i've got the same performance than with the display list.
it really is strange that the sphere is the fastest on your computer.
Cyrille
Le 09/03/2011 19:08, John Harrison a écrit :
Using Cyrille's test patch for speed which he sent into the list a week or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter.
http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj
maybe one with less vertices will help. I can try...
-John
On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclepper@gmail.com mailto:cgclepper@gmail.com> wrote:
A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much. On Wed, Mar 9, 2011 at 10:32 AM, John Harrison <johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com>> wrote: On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> wrote: hello, - try using a display list to render a sphere, so that every point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result. if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet... yes, the display list will help to render 1 single sphere. you have to call it 200 times. Ok I'm seeing a huge performance difference between using 200 of [sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time. This list is awesome. Where else could I find help like this? :-) -John _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- John http://alumni.media.mit.edu/~harrison/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It appears I'm actually getting better results from [gemlist] too with lighting off. But how do your results change with lighting on? For me, with lighting on, they seem about the same.
If you have your sphere.obj model with 900 triangles handy, I'd love to try it.
-John
On Wed, Mar 9, 2011 at 12:19 PM, cyrille henry ch@chnry.net wrote:
here, at 20fps, no lighting, i can draw about 500 model with your sphere.obj. 1000 sphere 30, and about 3500 display list of sphere 30. using an other sphere.obj with about 900 triangles, i've got the same performance than with the display list.
it really is strange that the sphere is the fastest on your computer.
Cyrille
Le 09/03/2011 19:08, John Harrison a écrit :
Using Cyrille's test patch for speed which he sent into the list a week or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter.
http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj
maybe one with less vertices will help. I can try...
-John
On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclepper@gmail.commailto: cgclepper@gmail.com> wrote:
A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much.
On Wed, Mar 9, 2011 at 10:32 AM, John Harrison < johnharrisonwsu@gmail.com mailto:johnharrisonwsu@gmail.com> wrote:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto:ch@chnry.net <mailto:ch@chnry.net mailto: ch@chnry.net>> wrote:
hello, - try using a display list to render a sphere, so thatevery point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would a display liststill help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 single sphere. you have to call it 200 times. Ok I'm seeing a huge performance difference between using 200 of[sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time.
This list is awesome. Where else could I find help like this? :-) -John _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management ->
with lighting on, things did not really change with the model or display list, but rendering sphere is 2 time slower.
here is the sphere.
Cyrille
Le 09/03/2011 20:44, John Harrison a écrit :
It appears I'm actually getting better results from [gemlist] too with lighting off. But how do your results change with lighting on? For me, with lighting on, they seem about the same.
If you have your sphere.obj model with 900 triangles handy, I'd love to try it.
-John
On Wed, Mar 9, 2011 at 12:19 PM, cyrille henry <ch@chnry.net mailto:ch@chnry.net> wrote:
here, at 20fps, no lighting, i can draw about 500 model with your sphere.obj. 1000 sphere 30, and about 3500 display list of sphere 30. using an other sphere.obj with about 900 triangles, i've got the same performance than with the display list. it really is strange that the sphere is the fastest on your computer. Cyrille Le 09/03/2011 19:08, John Harrison a écrit : Using Cyrille's test patch for speed which he sent into the list a week or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter. http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj <http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj> maybe one with less vertices will help. I can try... -John On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclepper@gmail.com <mailto:cgclepper@gmail.com> <mailto:cgclepper@gmail.com <mailto:cgclepper@gmail.com>>> wrote: A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much. On Wed, Mar 9, 2011 at 10:32 AM, John Harrison <johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com> <mailto:johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com>>> wrote: On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>> wrote: hello, - try using a display list to render a sphere, so that every point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result. if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet... yes, the display list will help to render 1 single sphere. you have to call it 200 times. Ok I'm seeing a huge performance difference between using 200 of [sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time. This list is awesome. Where else could I find help like this? :-) -John _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto: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
Ok so I did something stupid with the [GEMglLightModeliGL_LIGHT_MODEL_TWO_SIDE GL_FALSE] test which that I connected it to a [gemhead] instead of [gemhead 1]. When I corrected that I did find that indeed the performance changes drastically for the better. OTOH I couldn't get satisfactory lighting for my environment. It's a good technique for me to remember and I could probably make it work even for this project with enough experimentation of lighting sources and direction but...
it seems clear to me on my system at least with GL_LIGHT_MODEL_TWO_SIDE set to its default GL_TRUE the bottleneck is the lighting and any gains with a display list or model are lost because of the lighting issue. However I'm finding that I get satisfactory performance and appearance by changing the sphere to have 10 segments instead of 30. With a 10 segment sphere I can make 1000 spheres and straight-line curves at 20fps at about 70% draw on a CPU core. That works for me! :-)
I was curious if for a future project there might be a way I could make a shader that would emulate the local lighting effect and do it more efficiently. Serious exploration with shaders definitely needs to be in my future.
In any case, thanks for all the help!
-John
On Wed, Mar 9, 2011 at 1:55 PM, cyrille henry ch@chnry.net wrote:
with lighting on, things did not really change with the model or display list, but rendering sphere is 2 time slower.
here is the sphere.
Cyrille
Le 09/03/2011 20:44, John Harrison a écrit :
It appears I'm actually getting better results from [gemlist] too with lighting off. But how do your results change with lighting on? For me, with lighting on, they seem about the same.
If you have your sphere.obj model with 900 triangles handy, I'd love to try it.
-John
On Wed, Mar 9, 2011 at 12:19 PM, cyrille henry <ch@chnry.net mailto: ch@chnry.net> wrote:
here, at 20fps, no lighting, i can draw about 500 model with your sphere.obj. 1000 sphere 30, and about 3500 display list of sphere 30. using an other sphere.obj with about 900 triangles, i've got the same performance than with the display list.
it really is strange that the sphere is the fastest on your computer.
Cyrille
Le 09/03/2011 19:08, John Harrison a écrit :
Using Cyrille's test patch for speed which he sent into the list aweek or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter.
http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj <http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj%3E
maybe one with less vertices will help. I can try... -John On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclepper@gmail.com<mailto:cgclepper@gmail.com> <mailto:cgclepper@gmail.com mailto: cgclepper@gmail.com>> wrote:
A model is the way to go since the vertex data is static.Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much.
On Wed, Mar 9, 2011 at 10:32 AM, John Harrison <johnharrisonwsu@gmail.com mailto:johnharrisonwsu@gmail.com <mailto: johnharrisonwsu@gmail.com mailto:johnharrisonwsu@gmail.com>> wrote:
On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net mailto:ch@chnry.net <mailto:ch@chnry.net mailto: ch@chnry.net> <mailto:ch@chnry.net mailto:ch@chnry.net <mailto: ch@chnry.net mailto:ch@chnry.net>>> wrote:
hello, - try using a display list to render a sphere,so that every point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result.
if the spheres are all moving at once, would adisplay list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet...
yes, the display list will help to render 1 singlesphere. you have to call it 200 times.
Ok I'm seeing a huge performance difference between using200 of [sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time.
This list is awesome. Where else could I find help likethis? :-)
-John _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at<mailto: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
hello, i'm glad you find the bottleneck. but that's what i was afraid of : 2 side lighting are baddly suported on new nvidia hardware (at least on linux). (i mean : it's not only on my computer. it use to work fine).
But you should be able to get the same lighting with this option. this option only force to compute color 2 time per pixel : not only for the visible face, but for both face of the object.
So, if you got different lighting result, you just have to reverse some light orientation.
i never test performances optimisation using shaders for light.
cheers c
Le 10/03/2011 06:20, John Harrison a écrit :
Ok so I did something stupid with the [GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE GL_FALSE] test which that I connected it to a [gemhead] instead of [gemhead 1]. When I corrected that I did find that indeed the performance changes drastically for the better. OTOH I couldn't get satisfactory lighting for my environment. It's a good technique for me to remember and I could probably make it work even for this project with enough experimentation of lighting sources and direction but...
it seems clear to me on my system at least with GL_LIGHT_MODEL_TWO_SIDE set to its default GL_TRUE the bottleneck is the lighting and any gains with a display list or model are lost because of the lighting issue. However I'm finding that I get satisfactory performance and appearance by changing the sphere to have 10 segments instead of 30. With a 10 segment sphere I can make 1000 spheres and straight-line curves at 20fps at about 70% draw on a CPU core. That works for me! :-)
I was curious if for a future project there might be a way I could make a shader that would emulate the local lighting effect and do it more efficiently. Serious exploration with shaders definitely needs to be in my future.
In any case, thanks for all the help!
-John
On Wed, Mar 9, 2011 at 1:55 PM, cyrille henry <ch@chnry.net mailto:ch@chnry.net> wrote:
with lighting on, things did not really change with the model or display list, but rendering sphere is 2 time slower. here is the sphere. Cyrille Le 09/03/2011 20:44, John Harrison a écrit : It appears I'm actually getting better results from [gemlist] too with lighting off. But how do your results change with lighting on? For me, with lighting on, they seem about the same. If you have your sphere.obj model with 900 triangles handy, I'd love to try it. -John On Wed, Mar 9, 2011 at 12:19 PM, cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> wrote: here, at 20fps, no lighting, i can draw about 500 model with your sphere.obj. 1000 sphere 30, and about 3500 display list of sphere 30. using an other sphere.obj with about 900 triangles, i've got the same performance than with the display list. it really is strange that the sphere is the fastest on your computer. Cyrille Le 09/03/2011 19:08, John Harrison a écrit : Using Cyrille's test patch for speed which he sent into the list a week or so ago, I tried creating multiple spheres, gemlists, and models. The sphere is getting the best performance results, unfortunately. Attached is my test patch. I just connected [repeat] to either [sphere] [GEMglCallList] or [model] in the patch. The sphere model I used has probably got way too many points (just found it on the 'net) but my hope was that as the vertices were static it wouldn't matter. http://www.eecs.umich.edu/~guskov/eecs598-1/sphere.obj <http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj> <http://www.eecs.umich.edu/%7Eguskov/eecs598-1/sphere.obj> maybe one with less vertices will help. I can try... -John On Wed, Mar 9, 2011 at 9:48 AM, chris clepper <cgclepper@gmail.com <mailto:cgclepper@gmail.com> <mailto:cgclepper@gmail.com <mailto:cgclepper@gmail.com>> <mailto:cgclepper@gmail.com <mailto:cgclepper@gmail.com> <mailto:cgclepper@gmail.com <mailto:cgclepper@gmail.com>>>> wrote: A model is the way to go since the vertex data is static. Ideally for situations like this there would be one object that loads a single model and several clients that just call the display list. Although there is a lot of memory on GPUs now so 200 models of a sphere won't take up that much. On Wed, Mar 9, 2011 at 10:32 AM, John Harrison <johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com> <mailto:johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com>> <mailto:johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com> <mailto:johnharrisonwsu@gmail.com <mailto:johnharrisonwsu@gmail.com>>>> wrote: On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>> <mailto:ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>>>> wrote: hello, - try using a display list to render a sphere, so that every point don't have to be send for every sphere. see exemple 09.openGL/02.displaylist you can also use a model with a sphere.obj to have the same result. if the spheres are all moving at once, would a display list still help? Seems like recompilation would have to happen for every sphere for every frame? I haven't tried the model yet... yes, the display list will help to render 1 single sphere. you have to call it 200 times. Ok I'm seeing a huge performance difference between using 200 of [sphere <size-doesn't-matter> 20] and [sphere <size-doesn't-matter> 30]. Huge. So if I want to keep the sphere with 30 points, I'm thinking gemlist or model are my answer. I'll try both and report back, unless you have a strong recommendation for one or the other to save me time. This list is awesome. Where else could I find help like this? :-) -John _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list-- John http://alumni.media.mit.edu/~harrison/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 09/03/2011 02:16, John Harrison a écrit : oh, i forget :
These lines and spheres are nothing special, btw. No texturing, just translates, colors, and alpha. the lines are made with curves of 2 points each.
do you mean that you create [curve 2], or that you send a [res 2< message to the curve object? the res 2 message will use only 2 points to draw the curve. No need to have more to display a line....
c
-
chris clepper -
cyrille henry -
John Harrison