Rabbyt memory issue?

[Teatime]

I don't know if anyone is still alive in this group, but I have come
across a severe issue. I have a strange issue with rabbyt rendering.
For some time I have come across an issue where my application would
start up sometimes at 90%+ CPU usage and render at 0-2 FPS. Sometimes
it would load perfectly fine, full 60FPS with normal CPU usage, other
times the former. Hit or miss. I seem to have narrowed this down to
some sort of memory usage issue. If I have a few high memory usage
programs open on my computer (ones that take up 200-500MB of memory)
or more, the program absolutely comes to a crawl. If I close these
programs, it will start up normally. If I comment out the rendering,
it will load with 60 FPS and normal CPU usage.

I have over 6GB of useable memory on this machine, and nowhere near
the limit. I can run high performance games that takes up a gig of
memory or more, with these programs open without any hiccup at all. I
can't see how this would be a machine issue if this is the case.

If I comment my render functions (render_unsorted), the performance is
high again. I finally got around to using cProfiler and tried to see
any big differences between the two times, one where it fails and the
one where it passes. I will show the highlighted areas:

Mon Nov 29 03:21:30 2010 profiling (works)

3749430 function calls (3747493 primitive calls) in 29.972
CPU seconds

Ordered by: standard name

ncalls tottime percall cumtime percall
filename:lineno(function)
1 0.000 0.000 29.987 29.987 <string>:1(<module>)
1679 0.002 0.000 0.002 0.000 {rabbyt._anims.set_time}
1679 0.007 0.000 0.007 0.000 {rabbyt._rabbyt.clear}
153 0.058 0.000 0.058 0.000
{rabbyt._rabbyt.load_texture}
11753 0.053 0.000 0.053 0.000
{rabbyt._rabbyt.render_unsorted}
1 0.000 0.000 0.000 0.000
{rabbyt._rabbyt.set_default_attribs}
2 0.000 0.000 0.000 0.000
{rabbyt._rabbyt.unload_texture}
1679 0.014 0.000 0.014 0.000
{rabbyt.collisions.aabb_collide_single}

As you can see I let the program run for 30 seconds without doing
anything but moving the mouse to gauge how it ran. Everything seems
okay so far.

Here is how it looks when I the game slows to a crawl:

Mon Nov 29 03:11:52 2010 profiling (fails)

291202 function calls (290875 primitive calls) in 40.457 CPU
seconds

Ordered by: standard name

ncalls tottime percall cumtime percall
filename:lineno(function)
1 0.000 0.000 40.461 40.461 <string>:1(<module>)
54 0.000 0.000 0.000 0.000 {rabbyt._anims.set_time}
54 0.269 0.005 0.269 0.005 {rabbyt._rabbyt.clear}
153 0.207 0.001 0.207 0.001
{rabbyt._rabbyt.load_texture}
378 18.745 0.050 18.745 0.050
{rabbyt._rabbyt.render_unsorted}
1 0.000 0.000 0.000 0.000
{rabbyt._rabbyt.set_default_attribs}
2 0.000 0.000 0.000 0.000
{rabbyt._rabbyt.unload_texture}
63 0.000 0.000 0.000 0.000
{rabbyt.collisions.aabb_collide_single}

As you can see there is a big difference in rendering. The game as
only able to achieve 378 rendering calls and took forever on them,
when the program ran longer than the previous one. I really don't know
what to do regarding this. Any insight or help would be appreciated.

[Matthew Marshall]

Wow... I haven't seen anything like that before. I don't know what's
wrong, but maybe if I think out loud a bit I might say something that
helps... :-)

I don't know much about what you're drawing, other than that you're
loading 153 textures. Are these large textures? Are the other
applications you are running also using video memory? Perhaps the
slowdown is from the opengl implementation needing to swap (video)
memory. (Although I wouldn't think such a hit would be that big...
just thinking out loud.)

Some of the things that are happening in rabbyt.render_unsorted()

* render() on each sprite is called. (Make sure you aren't
overriding render() with a function that's killing you.)
* Anims are evaluated. (Make sure you aren't assigning anything
crazy to the animateable attributes.)
* OpenGL drawing calls. Try drawing all your sprites using a single,
small texture.

That last one is most likely the problem, but if replacing your
textures doesn't change anything, you can try ruling out the first
two.

That's all that comes to mind for now...

Sorry it took so long to moderate this message... I'm a little behind
on my emails.

MWM

> --
> You received this message because you are subscribed to the Google Groups "Rabbyt" group.
> To post to this group, send email to rab...@googlegroups.com.
> To unsubscribe from this group, send email to rabbyt+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rabbyt?hl=en.
>
>

[Teatime]

Sorry for the late reply.

They aren't really large textures. They are mostly small icons,
sprites, and tiles for the game I am working on. On Windows 7 all
applications do use some video memory however I have an application
that tells you how much video memory is in use and I have plenty
left.

- We have no custom render functions for sprites. All we have is a
layer than gathers all the sprites into a list then throws it to
render_unsorted. (On a side note for layering sprites, which would be
faster: Get background sprites, ground sprites, etc then render
unsorted each a row so they layer, or to render sort them?)

- As far as Anims I don't think there is anything crazy going on. We
just use it for camera and animations. I don't see anything different
than what most examples would put. I can double check though. (However
if this were the case, wouldn't animations ALWAYS produce this effect?
Just not sometimes?)

- So instead of loading a whole bunch of textures, just load that one,
and have it render to see if it works? That's a good idea. I'll try
next time I can.

On Dec 6 2010, 7:49 pm, Matthew Marshall <matt...@matthewmarshall.org>
wrote:

[Lily Surette]

I've just gotten into fiddling with Rabbyt myself, and while I haven't
developed anything major yet, I have also run into the odd occasion
where processor utilization would drastically increase without
reasonable cause (albeit not quite as bad as described in the OP -
only ~70% of a core used and no framerate collapse, probably because
I've only been testing out lerps and tex_shape remappings to do frame-
by-frame animation rather than a full game in progress, and as such
have no more than three or four textures loaded at a time).

So this might not be quite an isolated issue, and as such I'm willing
to offer any diagnostic info needed. Of course, I've had no luck
getting it to occur again while profiling, though - that's Murphy's
Law for ya.