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

[B. Bogart]

Here you go chris,

It looks about the same to me though, the only gem functions I'm seeing 
using a lot of CPU are colour conversion (I guess for the bttv capture)
and the rubber dynamics stuff.)

I don't understand how the CPU keeps increasing over time, since since the
patch is locked in a cycle. The cycle does capture more and more frames
over time into a buffer though. But if I stop the cycle so no new buffers
are captures, the CPU stays at 100%.

The machine is now on a highspeed network so I can setup an account if
anyone has the time and knowledge to help me with this.

I'm working on the rest of the stuff now, testing projectors, getting the
touchscreen driver installed, trying some other nvidia drivers...

.b.


On Wed, May 17, 2006 8:42 am, chris clepper said:
> 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 embedded and charset-unspecified text was scrubbed...
Name: profile_cgc.txt
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060517/d557d66e/attachment.txt>