{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]

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
>