Gem sucking whole CPU for no visible reason... intermitently WAS Re: [GEM-dev] Re: [PD-dev] oprofile - streamlining Pd/gem patch

[chris clepper]

Try getting the call stack for Gem.  This should trace the GL driver
function back to the Gem call that triggered it.  Following Tim's link above
try opreport -cl --demangle=smart

Having something that does more that dump a billion lines of text to the
console will help immensely in sorting out the profile.

On 5/17/06, B. Bogart <ben at ekran.org> wrote:
>
> Hi Chris,
>
> I'm trying to do some google searching on how to debug the nvidia binary
> driver, but looks like (perhaps) only nvidia can do that...
>
> Anyhow attached is the oprofile with the function calls, which does not
> tell me about anything in Gem I did not already know, and the two biggest
> calls, for rubber and the colour conversion, add up to 14%. 50% is sucked
> up by the black box of libGLCore.
>
> The newer nvidia driver I installed yesterday does help, it takes longer
> for the CPU to get up to 100%, but certainly not not fix the problem.
>
> If anyone knows:
> A: how to get more info about what the hell libGLcore is doing
> B: what the heck "zero" is and why its using 12% CPU
>
> If I can't get anywhere on this today I guess I'll have to keep rebooting
> the machine each 2hrs or so, I will be baby sitting it anyhow, and it is
> only 2 days, but the next installation is going to be 3 days starting May
> 23rd.
>
> Thanks,
> .b.
>
> n Tue, May 16, 2006 6:52 pm, chris clepper said:
> > I think you need a better profiler which traces the calls.  Just listing
> > the
> > libs is only marginally more useful than top.  There's nothing to
> indicate
> > if the driver is spending time uploading textures or vertices or just
> > waiting for the GPU or doing something stupid. Without that info there
> is
> > little anyone can do to fix any problems.
> >
> > On 5/16/06, B. Bogart <ben at ekran.org> wrote:
> >>
> >> Hey all,
> >>
> >> So I'm going to leave the patch on overnight and *HOPE* that it does
> not
> >> due the weird spike while I'm gone.
> >>
> >> Right now this is what the profile looks like:
> >>
> >>           5028091 51.5756 libGLcore.so.1.0.8756
> >>           2287523 23.4643 Gem.pd_linux
> >>           1155076 11.8482 zero
> >>            402984  4.1336 pd
> >>            336232  3.4489 libfreetype.so.6.3.5
> >>            210094  2.1550 libc-2.3.6.so
> >>            179207  1.8382 libm-2.3.6.so
> >>             75334  0.7727 libGL.so.1.0.8756
> >>             63900  0.6555 libX11.so.6.2
> >>              4586  0.0470 libpthread-2.3.6.so
> >>              3691  0.0379 libGLU.so.1.3
> >>              1618  0.0166 comport.pd_linux
> >>               199  0.0020 expr.pd_linux
> >>               182  0.0019 libpython2.3.so.1.0
> >>                78 8.0e-04 zexy.pd_linux
> >>                72 7.4e-04 libstdc++.so.6.0.8
> >>                46 4.7e-04 py.pd_linux
> >>                30 3.1e-04 xsample.pd_linux
> >>                17 1.7e-04 pool.pd_linux
> >>                11 1.1e-04 prepend.pd_linux
> >>
> >> So the question is, what the heck is "zero" and why is pd linked with
> >> it???
> >>
> >> I really hope this newer binary fixes the issue.
> >>
> >> Thanks all for your help.
> >>
> > _______________________________________________
> > GEM-dev mailing list
> > GEM-dev at iem.at
> > http://lists.puredata.info/listinfo/gem-dev
> >
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060517/fa85cede/attachment.htm>