Hair: Unexpectedly long sync times #37302

New Issue

xxxxx xxxxx · 2013-11-04T02:29:25+01:00

xxxxx xxxxx commented

2013-11-04 02:29:25 +01:00

%%%--- Operating System, Graphics card ---
Arch x64, Phenom II 1055T, 16GB RAM

- Blender version with error, and version that worked ---

self-built r61073

- Short description of error ---

after noticing that 1M hairs seemed to take a bit longer to synchronize than expected, i set up a little test (CPU only, SVM)

these somewhat non-scientific tests were all done by adding a hair particle system to the default cube, and stopping the render right after (well during, technically) the synchronization stage.

children were set to interpolated
viewport visibility was disabled for the modifier for all of these tests
all other particle settings were left as default

1k parents

10 children: instant
50 children: ~1.5s
100 children: ~4s
500 children: ~44s
1k children: ~5m45s (yes, really)
5k children: ~2h23m32s (... yep)
10k children: ~30s (???, let it render out of curiousity, but CTD'd during BVH building)
50k children: CTD

10k parents

10 children: ~4s
50 children: ~45s
100 children: ~5m45s
500 children: didn't actually bother with this one, if the 1k/5k test was any indication
1k children: ~38s, also CTDs
5k children: ...system hung, didn't try again

wacky.

Notes:
- each test was performed with a freshly-opened blender
- the 500K, 1M, and 10M tests were consistent for the 2 or 3 times i ended up running them (and after i restarted from that hang)
- i tried gprof (with a separate build), and with one of those tests (1k/1k iirc), BLI_qsort_r accounted for pretty much the entire runtime. the comment in /blenkernel/intern/particle_system.c:1332 gives me the impression the "optimization" is specific to BI? i probably shouldn't speculate about this lol

%%%

%%%--- Operating System, Graphics card --- Arch x64, Phenom II 1055T, 16GB RAM - Blender version with error, and version that worked --- self-built r61073 - Short description of error --- after noticing that 1M hairs seemed to take a bit longer to synchronize than expected, i set up a little test (CPU only, SVM) these somewhat non-scientific tests were all done by adding a hair particle system to the default cube, and stopping the render right after (well during, technically) the synchronization stage. - children were set to interpolated - viewport visibility was disabled for the modifier for all of these tests - all other particle settings were left as default 1k parents - 10 children: instant - 50 children: ~1.5s - 100 children: ~4s - 500 children: ~44s - 1k children: ~5m45s (yes, really) - 5k children: ~2h23m32s (... yep) - 10k children: ~30s (???, let it render out of curiousity, but CTD'd during BVH building) - 50k children: CTD 10k parents - 10 children: ~4s - 50 children: ~45s - 100 children: ~5m45s - 500 children: didn't actually bother with this one, if the 1k/5k test was any indication - 1k children: ~38s, also CTDs - 5k children: ...system hung, didn't try again wacky. Notes: - each test was performed with a freshly-opened blender - the 500K, 1M, and 10M tests were consistent for the 2 or 3 times i ended up running them (and after i restarted from that hang) - i tried gprof (with a separate build), and with one of those tests (1k/1k iirc), BLI_qsort_r accounted for pretty much the entire runtime. the comment in /blenkernel/intern/particle_system.c:1332 gives me the impression the "optimization" is specific to BI? i probably shouldn't speculate about this lol %%%

xxxxx xxxxx commented

2013-11-04 02:29:25 +01:00

Changed status to: 'Open'

xxxxx xxxxx commented

2013-11-05 19:23:52 +01:00

%%%those CTDs do in fact happen due to running out of ram, the 1k/1k test case peaks at about 1.5gb during the bvh building, so...

also as a test i commented out that if statement containing the qsort call, and it drops the 1k/1k case down to around 3 seconds, and the 1k/5k case to 15 seconds; quite a lot closer to the linear increase i expected.

however i don't know whether this is a valid solution as far as cycles is concerned

EDIT: since blender moved to git i just put this workaround fix in its own branch to use as my main build until a proper fix is found. i'm actually getting much better times this time around then when i tried the fix the last time... odd (although last time i didn't comment out the if... maybe gcc wasn't eliminating it or something)%%%

%%%those CTDs do in fact happen due to running out of ram, the 1k/1k test case peaks at about 1.5gb during the bvh building, so... also as a test i commented out that if statement containing the qsort call, and it drops the 1k/1k case down to around 3 seconds, and the 1k/5k case to 15 seconds; quite a lot closer to the linear increase i expected. however i don't know whether this is a valid solution as far as cycles is concerned EDIT: since blender moved to git i just put this workaround fix in its own branch to use as my main build until a proper fix is found. i'm actually getting much better times this time around then when i tried the fix the last time... odd (although last time i didn't comment out the if... maybe gcc wasn't eliminating it or something)%%%

blender-admin commented

2014-01-23 18:14:19 +01:00

This issue was referenced by blender/blender-addons-contrib@b119f471f4

This issue was referenced by blender/blender-addons-contrib@b119f471f4c5bd20975091259a0da6ce155180e6

blender-admin commented

2014-01-23 18:14:19 +01:00

This issue was referenced by b119f471f4

This issue was referenced by b119f471f4c5bd20975091259a0da6ce155180e6

Brecht Van Lommel commented

2014-01-23 18:15:08 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue