Cycles: Reduce memory usage by de-duplicating triangle storage
authorSergey Sharybin <sergey.vfx@gmail.com>
Fri, 10 Jun 2016 14:13:50 +0000 (16:13 +0200)
committerSergey Sharybin <sergey.vfx@gmail.com>
Thu, 7 Jul 2016 15:25:48 +0000 (17:25 +0200)
commit17e745426375fe76f5011992d582c01b682d348b
treef14a9f2fe707e63396cc2a509b87201976adfdbd
parent1eacbf47e3cdf009b27972e1c617fb1ff56c0aad
Cycles: Reduce memory usage by de-duplicating triangle storage

There are several internal changes for this:

First idea is to make __tri_verts to behave similar to __tri_storage,
meaning, __tri_verts array now contains all vertices of all triangles
instead of just mesh vertices. This saves some lookup when reading
triangle coordinates in functions like triangle_normal().

In order to make it efficient needed to store global triangle offset
somewhere. So no __tri_vindex.w contains a global triangle index which
can be used to read triangle vertices.

Additionally, the order of vertices in that array is aligned with
primitives from BVH. This is needed to keep cache as much coherent as
possible for BVH traversal. This causes some extra tricks needed to
fill the array in and deal with True Displacement but those trickery
is fully required to prevent noticeable slowdown.

Next idea was to use this __tri_verts instead of __tri_storage in
intersection code. Unfortunately, this is quite tricky to do without
noticeable speed loss. Mainly this loss is caused by extra lookup
happening to access vertex coordinate.

Fortunately, tricks here and there (i,e, some types changes to avoid
casts which are not really coming for free) reduces those losses to
an acceptable level. So now they are within couple of percent only,

On a positive site we've achieved:

- Few percent of memory save with triangle-only scenes. Actual save
  in this case is close to size of all vertices.

  On a more fine-subdivided scenes this benefit might become more
  obvious.

- Huge memory save of hairy scenes. For example, on koro.blend
  there is about 20% memory save. Similar figure for bunny.blend.

This memory save was the main goal of this commit to move forward
with Hair BVH which required more memory per BVH node. So while
this sounds exciting, this memory optimization will become invisible
by upcoming Hair BVH work.

But again on a positive side, we can add an option to NOT use Hair
BVH and then we'll have same-ish render times as we've got currently
but will have this 20% memory benefit on hairy scenes.
intern/cycles/bvh/bvh.cpp
intern/cycles/bvh/bvh.h
intern/cycles/kernel/geom/geom_motion_triangle.h
intern/cycles/kernel/geom/geom_triangle.h
intern/cycles/kernel/geom/geom_triangle_intersect.h
intern/cycles/kernel/kernel_textures.h
intern/cycles/render/mesh.cpp
intern/cycles/render/mesh.h
intern/cycles/render/scene.h