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

B. Bogart ben at ekran.org
Wed May 17 19:12:05 CEST 2006


What confuses me is the weird jumps, the patch sits there happy at 50% for
an hour, then slowly it goes up, get a few 100% spikes, then blocks, then
the whole machine is up to 100% constantly.

without rubber and w/ the reduced separators (taking out the text3d) the
patch is using 10% CPU.

55% gem
20% pd
20% Glcore

I guess I'll try building it up slowly...

If anyone has a patch with the matrix pop/push "separator" replacement
please send it along. Or will that behave as badly as [separator]?

arg.

.b.

On Wed, May 17, 2006 1:06 pm, B. Bogart said:
> Thanks chris,
>
> in some cases it does seem possible to remove the separators, in others I
> suppose I would have to use matrixpop and matrixpush... anyone have an
> example patch of this?
>
> so I removed many of the separators from my patch and we'll see if that
> improves things.
>
> The patch seemed to be running fine before I put in [rubber], the
> abstraction that contains the rubber stuff is [single-moment]. But now
> that I think about it its probably just because the drop of frame-rate is
> only visible with rubber in it, maybe it was always doing this, but I
> don't recall so... I did upgrade gnome, but it seems very unlikely that
> would cause these troubles.
>
> Yes its a pan/tilt/zoom camera. (but even if its the same static frame the
> patch should still act the same...)
>
> I'm going to profile it now while its running fine.
>
> Thanks again Chris, I appreciate your time. I'm sitting on #dataflow if
> you have any more questions.
>
>
> .b.
>
> On Wed, May 17, 2006 12:23 pm, chris clepper said:
>> On 5/17/06, B. Bogart <ben at ekran.org> wrote:
>>> 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
>>
>>
>> That many separators will likely stall the GPU quite a bit since that
> basically resets the rendering pipeline.  That many pix_texture objects
> constantly uploading textures will also stall in the driver on Linux and
> Windows (your patch would probably go like 0.2 fps on Windows).
>>
>> 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?
>>
>>
>> The profiler will take note of any memory location in the driver that
>> takes
>> time and then it should also keep track of what calls lead up to it.  So
>> if
>> you do a glColor4f() in GEM that will make the driver do something with
> that
>> call.
>>
>> The symbols in the driver aren't all that important unless there is a
> bug
>> to
>> alert Nvidia about.
>>
>> attached is the patch, though it depends on pix_video uses in a weird
> way,
>>> and my serial control camera
>>
>>
>> A  Pan/Tilt/Zoom camera?
>>
>> cgc
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>>
>
>
>
>
>






More information about the GEM-dev mailing list