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

[B. Bogart]

Sorry I forgot the attachments.

..b..

Anyone have an nvidia contact I could send this stuff to? I think its far
over the head of the "knowledgebase forums".


On Wed, May 17, 2006 8:28 am, B. Bogart said:
> 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
>>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile_symbols.log
Type: text/x-log
Size: 22038 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060517/ad2a17a5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile_details.log
Type: text/x-log
Size: 860476 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060517/ad2a17a5/attachment-0001.bin>