non-realtime cpu issues (using render_node)


    Mar 30 2006 | 8:52 pm
    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 320x240 raw against 800x600 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 :-/
    Thijs

    • Mar 30 2006 | 9:21 pm
      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).
      Good luck.
      -Joshua
    • Mar 30 2006 | 9:36 pm
    • Mar 30 2006 | 9:39 pm
      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.
      cheers
      bruce
      bruce tovsky
      www.skeletonhome.com
      "Reality is whatever refuses to go away when I stop believing in it.."
      Philip K. Dick
    • Mar 30 2006 | 10:05 pm
      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.
      Best, T_
    • Apr 01 2006 | 5:17 pm
      M/M/J has not yet been released for the new Intel Macs.
      best,
      dan
      --
      ***
      http://danwinckler.com
      http://share.dj