non-realtime cpu issues (using render_node)
I am using Randy Jones his render_node patch to render some video’s. It
switches max to non-realtime to render every frame. The problem is
max/jitter takes a very long time to render things that it can do in
realtime. I have a jitter patch running at about 60% cpu usage in realtime.
When I start recording it, it records at about 1 fps. The example patch that
comes with render_node is showing the same behavior.
The weird thing is that max itself shows 100% cpu usage, while my
taskmanager shows its doing almost nothing. The max interface is jammed
like it would be at 100%, but I can keep on using other programs without
problems. My computer even turns on its screensaver after a while, and it
doesn’t interfere with anything.
I stripped down the patch to where its basically only rendercontext ->
to_texture -> jit.qt.record, bypassing the frame accumulations and plugins,
but without luck. Also the movie size and codec doesn’t make much of a
difference. Rendering 320×240 raw against 800×600 jpeg, still about 1fps.
I also tried changing the dsp settings. As far as I know Randy doesn’t know
what’s up either, and I suppose its the same on mac as it is on my windows
system. I’m wondering if someone can tell me something relevant about this
realtime mode. Am I missing something? Does anyone have similar experience
with non-realtime mode?
I recently had to wait for 3 hours to render a 4,5min movie :-/
On Mar 30, 2006, at 12:52 PM, Thijs Koerselman wrote:
> I also tried changing the dsp settings. As far as I know Randy
> doesn’t know what’s up either, and I suppose its the same on mac as
> it is on my windows system. I’m wondering if someone can tell me
> something relevant about this realtime mode. Am I missing
> something? Does anyone have similar experience with non-realtime mode?
Well sfplay~ and sfrecord in NRT mode perform synchronous disk access
and are *quite* slow as a result. NRT mode is primarily in place for
us to debug MSP objects, and though it is useful for tasks like this,
it doesn’t warrant the considerable oevrhaul that would be necessary
to speed up sfplay~ and sfrecord~ in this case. The work around is to
record into a buffer~ with record~ and then export the buffer~ to
AIFF at the final stage. I guarantee that this will be noticably
faster than using sfplay~/sfrecord~ in NRT mode (and I believe this
is floating around the maxmsp mailing list archives somewhere.
I have a hunch that this is where your bottleneck lies, but if not,
keep stripping your patch down, disabling MSP and DSP in NRT, etc.
until you come to a conclusion as to where the precise bottleneck
lies. Shark (part of Apple’s excellent CHUD tools, downloadable from
their developer site) may prove useful for determining what is taking
the performance hit, though it can be misleading in situations where
MaxMSP is spending all it’s time waiting on synchronous disk I/O (and
thus not showing up much in the process monitor or in shark).
On Mar 30, 2006, at 3:52 PM, Thijs Koerselman wrote:
> I recently had to wait for 3 hours to render a 4,5min movie :-/
while i haven’t had time to check out render_node yet ,this is not
unusual for off-line rendering in general. a lot of my work entails
the use of high end compositing programs like after effects where
several seconds of hi-rez video can take hours.
"Reality is whatever refuses to go away when I stop believing in it.."
Philip K. Dick
Thanks!! I just deleted the audio recording part, and it’s rendering in
realtime speed now :-) x30 speed up! Awesome. I read about this in the
archives just after posting my mail… stupid me.