hey,
...I've got a model that's fairly large and seems to be causing our model-loading display system some problems: almost immediately pd/ gem start to eat up 100%cpu...this also happens when using [vertex_model]:
vertex_model: model->numtriangles 62692 vertex_model: model->numgroups 2 vertex_model: model->numvertices 143258 vertex_model: model->numnormals 143860 vertex_model: model->numtexcoords 143258 vertex_model: i 0 vertex_model: src2 94038 vertex_model: src4 188076
...anyway, according to shark, 98% of the cpu time is now being spent recursively in GemBase::continueRender(), and I'm not really sure why this would be, or what that function's actual duty is? Most of the time I'm seeing about 4 levels of the following:
GemBase::continueRender GemBase::gem_renderMess GemBase::gem_MessCallback pd_typedmess outlet_anything
...is continueRender called when an object isn't finished doing it's thing? Or does anyone have other ideas about what's going on?
jamie
hi
james tittle wrote: [...]
GemBase::continueRender GemBase::gem_renderMess GemBase::gem_MessCallback pd_typedmess outlet_anything
...is continueRender called when an object isn't finished doing it's thing? Or does anyone have other ideas about what's going on?
first, i don't yet know what is going on.
second: the continueRender() is called to emit a render-message through the 1st outlet; so it just means: "render the gemchain below this object".
i don't really see where it should hang there, but i guess we could make some optimizations, like not calling gensym("gem_state") in each run but referring to a pre-initialized symbol-pointer; and use an only-once allocated t_atom-array (this is really the _only_ line of code where i could expect the time to be spent.
however, i don't see any relation between a large model to be loaded and the behaviour of continueRender(). is there anything else in the patch where the continueRender() might be called more often than once in a render cycle (esp. [part_info] or [part_render])?
mfgadsr IOhannes
hi IO,
On Aug 10, 2006, at 4:18 AM, IOhannes m zmoelnig wrote:
however, i don't see any relation between a large model to be loaded and the behaviour of continueRender().
...yeh, size was the most obvious difference at first...I've now tried it with the venus.obj and don't get the same behaviour, tho, so maybe it's a problem with the model in general?
is there anything else in the patch where the continueRender() might be called more often than once in a render cycle (esp. [part_info] or [part_render])?
...no, this is just a "[gemhead]->[vertex_model]->[vertex_draw]"- kinda patch ;-) I did notice that there were somethings that were multiple-y connected to inlets (ie. old chains that had been "short- circuited" from the gemhead without being removed from the latter active chain)...by this, I mean that I had a [vertex_program] between [gemhead] and [vertex_model], and to test it without [vertex_program], I just disconnected [gemhead]->[vertex_program] and connected [gemhead]->[vertex_model], but left [vertex_program] still connected to [vertex_model]'s inlet...doesn't seem like that should have any effect, right?
...anyway, this means I need to keep working on this stuff, anyway...
jamie
Bad Shark trace? What does OGLProfiler say?
62k triangles is a fair amount. I would expect the memcpy() from the cache to the GemState to eat the most time.
On 8/9/06, james tittle tigital@mac.com wrote:
hey,
...I've got a model that's fairly large and seems to be causing our model-loading display system some problems: almost immediately pd/ gem start to eat up 100%cpu...this also happens when using [vertex_model]:
vertex_model: model->numtriangles 62692 vertex_model: model->numgroups 2 vertex_model: model->numvertices 143258 vertex_model: model->numnormals 143860 vertex_model: model->numtexcoords 143258 vertex_model: i 0 vertex_model: src2 94038 vertex_model: src4 188076
...anyway, according to shark, 98% of the cpu time is now being spent recursively in GemBase::continueRender(), and I'm not really sure why this would be, or what that function's actual duty is? Most of the time I'm seeing about 4 levels of the following:
GemBase::continueRender GemBase::gem_renderMess GemBase::gem_MessCallback pd_typedmess outlet_anything
...is continueRender called when an object isn't finished doing it's thing? Or does anyone have other ideas about what's going on?
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hey chris,
On Aug 10, 2006, at 11:13 AM, chris clepper wrote:
Bad Shark trace? What does OGLProfiler say?
62k triangles is a fair amount. I would expect the memcpy() from the cache to the GemState to eat the most time.
...well, if it is a bad shark trace, then it's highly reproducible ;-\
...As expected, OglProfiler reports that we spend only ~2% of app time in GL, and of that, ~63% is in glBufferData(), which would be expected...it does remind me that I need to switch [vertex_draw] to not always using glBufferData(), but instead use glMapBuffer/ glUnMapBuffer or glBufferSubData() if the data hasn't changed size...
jamie
-
chris clepper -
IOhannes m zmoelnig -
james tittle