Modified 139 timetest

Preview
Modified 139 timetest

Description

A timing test for re-rendering 139 in a new version
Testing how long it takes to render a single frame of the modified 139.

Message boards : Comments and discussion : 690

Author Message
AC
Project donor
Avatar
Send message
Joined: 30 Sep 07
Posts: 121
Credit: 143,874
RAC: 0
Message 7030 - Posted: 21 Nov 2007, 17:52:47 UTC

This anim seems to be crashing on boxes with less than 1GB RAM. It might make sense to up the RAM requirement. Upping the quadtree resolution might speed up the renders as well... at least it did for the very few tests I ran.

Good to have BURPing to do again at last -- thanks Janus!

AC
Project donor
Avatar
Send message
Joined: 30 Sep 07
Posts: 121
Credit: 143,874
RAC: 0
Message 7033 - Posted: 21 Nov 2007, 21:56:44 UTC

I checked again and the problem seems to be more like a small group of computers that are crashing often (every 45 seconds in one case) -- and a couple of them *do* have a gig or more of RAM.

Also, I ran a couple more tests with different octree resolutions, and here are the results:

MEM_XP is the memory used by the blender process according to WinXP\'s Task Manager.
Tests were run with oversampling and motion blur disabled, 25% size, 1x1 parts, frame #499.

OCTREE TIME MEM_XP 512 -> 20:38.09 102 MB 256 -> 18:44.48 94 MB 128 -> 22:47.56 92 MB 64 -> 57:05.14 92 MB

Profile Janus
Volunteer moderator
Project administrator
Avatar
Send message
Joined: 16 Jun 04
Posts: 4478
Credit: 2,094,806
RAC: 0
Message 7036 - Posted: 22 Nov 2007, 7:28:53 UTC - in response to Message 7033.

A very good point. Given the fact that this is something that people often forget I really should look into how to autodetect it... and since the Bittorrent subproject has been paused for a while this may just be what I\'ll do.

AC
Project donor
Avatar
Send message
Joined: 30 Sep 07
Posts: 121
Credit: 143,874
RAC: 0
Message 7043 - Posted: 22 Nov 2007, 16:52:16 UTC - in response to Message 7036.

I had considered making a script to run test renders at each setting and just see which one finishes first*, but I see there\'s already a little bit of scorekeeping in Blender\'s octree source (ray.c:430) for debugging purposes... Since you\'re already patching Blender, maybe that would be a better solution.

* there\'s probably no need to render full frames or to let the frames finish -- just see which one is rendering faster, after accounting for the startup time...


Post to thread

Message boards : Comments and discussion : 690