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@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