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

[B. Bogart]

Hi Chris,

Here is the best count I can come up with (time permitting)

1 pix_video
6 gemheads
3 pix_texture
3 rectangle
1 pix_buffer_read
1 gemmouse
5 translate
3 rotate
3 scale
3 color
3 alpha
4 ortho
1 separator

20 instances of the same abstraction:
(these are counts of the totals for the whole patch)
40 gemheads
100 pix_texture
120 rectangle
20 pix_buffer
60 pix_buffer_read
20 pix_buffer_write
160 translate
80 scale
20 color
40 alpha
160 separator

I really have no idea how the nv driver works, what your saying tells me
that each gem GL function should execute a function in the nvidia driver.
But since the driver is closed source without symbols would there be any
way of getting those calls?

What I know for sure:

happens on the nvidia driver 7xxx and 8xxx.

The less copies of the abstraction I use the better is gets, that is the
CPU  increase takes longer, so it runs fine for longer. It also means gem
captures less frames and therefore uses less memory.

It does not seem to happen with only 1 copy of the abstraction, but that
probably just means that it would so be prolonged that i can't see the
increase of CPU cycles.

attached is the patch, though it depends on pix_video uses in a weird way,
and my serial control camera (and rubber from a recent CVS gem) load with
-noloadbang first and remove what you know will not work. search for
pix_video as well!

Thanks so much for keeping the dialog going.
.b.

On Wed, May 17, 2006 10:37 am, chris clepper said:
> On 5/17/06, B. Bogart <ben at ekran.org> wrote:
>>
>> 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.)
>
>
> That is not all that helpful.  Surely there is a way to get the real call
> tree.  All of the time spent in libGLcore should be traced back to calls
> in
> GEM.  That info is useful in your situation.
>
> Can you just list the numbers of non-pix GEM objects you are using?
>
> 2 pix_texture
> 4 colorRGB
> etc
>
> cgc
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resurfacing.tgz
Type: application/x-compressed-tar
Size: 216211 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20060517/f9a689f2/attachment.bin>