No subject
Tue Mar 8 10:40:04 CET 2011
o
difference.
> - don't forget to check that you CPU run fullspeed. (sometimes pd use mor=
e
> 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 =E9crit :
>
>> I'm working with a high-powered machine but I'm running into a bottlenec=
k
>> with Gem. I'm running at 20fps and at times was intending to have as man=
y 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 renderin=
g,
>> 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 m=
y
>> 200+ intention while saturating my computational limits. If I turn light=
ing
>> 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_shar=
e to
>> recombine them in a "master" instance. I'd have to use pix_snap to captu=
re
>> each of the Gem windows in each of the processes, and each one draws abo=
ut
>> 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 do=
n't
>> know how the graphics card is fitting into all of this, if it would beco=
me 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 point=
s
>> each.
>>
>> Is there some trick or some area of programming or using the graphics ca=
rd
>> 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 be=
tter
>> than on my not-so-special laptop.
>>
>> This machine has Nvidia GeForce GTX 460, Ubuntu 10.10 32 bit, Pd-extende=
d
>> 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 instanc=
e 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, guy=
s!
>> :-)
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
--0016e6de1542c00972049e0d7538
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
thanks for these suggestions. Here's how it's going so far:<br><br>=
<div class=3D"gmail_quote">On Wed, Mar 9, 2011 at 1:59 AM, cyrille henry <s=
pan dir=3D"ltr"><<a href=3D"mailto:ch at chnry.net">ch at chnry.net</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">hello,<br>
<br>
- try using a display list to render a sphere, so that every point don'=
t have to be send for every sphere.<br>
see exemple 09.openGL/02.displaylist<br>
you can also use a model with a sphere.obj to have the same result.<br></bl=
ockquote><div>=A0</div><div>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...<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;=
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
- gemhead are slow. i usually have better result using 1 gemhead and 200 se=
parator, or 200 gemlist, than using 200 gemhead.<br></blockquote><div>=A0</=
div><div>It actually performed marginally slower with 1 gemhead and 200 sep=
and also slower with 200 gemlist <br>
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;=
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
- try to put somewhere :<br>
[gemhead 1]<br>
[GEMglLightModeli GL_LIGHT_MODEL_TWO_SIDE GL_FALSE]<br>
<br>
it help a lot on my computer (GT 425M), but i don't know on other compu=
ter.<br>
could you try and tell me the performance improvement?<br>
(you may have to reverse some light to have close lighting result).<br></bl=
ockquote><div><br>From your earlier email thread on this list, I already tr=
ied that before. No difference. <br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 20=
4, 204); padding-left: 1ex;">
<br>
- don't forget to check that you CPU run fullspeed. (sometimes pd use m=
ore than 100% cpu, but the cpu monitor fail to detect that and the cpu stil=
l run at low speed)<br></blockquote><div>=A0</div><div>yeah it appears that=
happened, but forcing the CPU to run full speed makes no difference for so=
me reason.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
- start pd -noaudio if it is an option.<br></blockquote><div><br>Already wa=
s done.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt=
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
- you can separate the physical model and the other calculation in a separa=
te pd instance than Gem. using pd~. This may help<br></blockquote><div>=A0<=
/div><div>If I turn off rendering, CPU usage with physical model being calc=
ulated hovers at about 4%, so this doesn't seem worth the effort. Am I =
missing something?<br>
<br>Sending [res 2( to curve also made no difference.<br>=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
well, i think all of this should be enough to draw 10 time more spheres tha=
t what you need, at a good fps.<br></blockquote><div>=A0</div><div>So far m=
y mileage is varying! :-) <br><br>Thanks for the help. I guess I'll try=
the model next.<br>
<br>-John<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0=
pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
">
<br>
Cyrille<br>
<br>
Le 09/03/2011 02:16, John Harrison a =E9crit :<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><=
div class=3D"h5">
I'm working with a high-powered machine but I'm running into a bott=
leneck with Gem. I'm running at 20fps and at times was intending to hav=
e as many as 200+ lines and spheres on a 1024x768 screen. At around 60 line=
s/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 o=
ther manipulations I use periodically too causing another 40%+ of CPU so I&=
#39;m a far cry from my 200+ intention while saturating my computational li=
mits. If I turn lighting off, BTW, I already gain 10% CPU back (not an opti=
on I want to explore.)<br>
<br>
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 besi=
des creating a headache for myself this is going to be a lot of CPU overhea=
d. 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? :-)<br>
<br>
These lines and spheres are nothing special, btw. No texturing, just transl=
ates, colors, and alpha. the lines are made with curves of 2 points each.<b=
r>
<br>
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.<br>
<br>
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 p=
roprietary driver 290.19.06.<br>
<br>
When I say stuff like "40% CPU" I mean for a single core. So in t=
heory this machine has 800% CPU limit in my nomenclature. But since an inst=
ance of Pd/Gem runs on only a single core, I have a limit of 100% for any s=
ingle Pd/Gem instance (as most of you already know I'm sure.)<br>
<br>
-John<br>
<br>
P.S. I'm loving working with Gem and pmpd these days. Awesome stuff, gu=
ys! :-)<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></div></div>
_______________________________________________<br>
<a href=3D"mailto:Pd-list at iem.at" target=3D"_blank">Pd-list at iem.at</a> mail=
ing list<br>
UNSUBSCRIBE and account-management -> =A0<a href=3D"http://lists.puredat=
a.info/listinfo/pd-list" target=3D"_blank">http://lists.puredata.info/listi=
nfo/pd-list</a><br>
</blockquote>
</blockquote></div><br><br clear=3D"all"><br>
--0016e6de1542c00972049e0d7538--
More information about the Pd-list
mailing list