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