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@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@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@iem.at
> http://lists.puredata.info/listinfo/gem-dev
>



_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev