[Soc-2018-dev] Weekly Report #4 - Further Development for Cycles' Volume Rendering

[Geraldine Chua]

Hi Stefan!

Thanks for the comments, I really appreciate the feedback and suggestions.

This we can eventually take a look at in a profiler. Maybe with some
> changes to the memory layout (morton order in tiles?) we can get a better
> cache utilisation from the tiled cache.
>

I just tried out morton ordering tiles in the sparse grid, and the time
savings are great! With the same sample image as the weekly report, render
time dropped to 9:17, which is 0.94x the original speed. Morton ordering
also requires less calculation to get the sparse voxel index, which
definitely speeds up the render.

This is something that eventually will need benchmarking. The old
> assumptions of memory vs speed tradeoffs and using lookup tables to save a
> few calculations don’t necessarily hold true any more with modern memory
> architectures, especially on GPUs. A memory lookup through a cache miss can
> take hundreds of cycles, while the processor can execute several additions
> or multiplications in a single cycle.
>

This didn't occur to me, I guess I got stuck on the old thinking of
multiplication/division being too expensive. I will try out both ways and
compare the results once I have access to some graphics cards.

You can also take a look at the work that Luca Rood has done for Tangent
> Animation in their branch:
>

I haven't had the time until now but I'll definitely read up on this.
Thanks for pointing me in the right direction :)

Best regards,
Geraldine


On Thu, Jun 14, 2018 at 3:59 PM, Stefan Werner <stewreo at gmail.com> wrote:

> Hi Geraldine!
>
> My comments are inlined.
>
> On 10. Jun 2018, at 18:04, Geraldine Chua <chua.gsk at gmail.com> wrote:
>
>
> Memory usage of 'color' (__tex_image_float4_000) reduced from 3.06M to
> 2.50M (18.3% reduction)
> Memory usage of 'density' (__tex_image_float_003) reduced from 783.75K to
> 644.00K (17.8% reduction)
> Memory usage of 'flame' (__tex_image_float_011) reduced from 783.75K to
> 292.00K (62.7% reduction)
> Memory usage of 'temperature' (__tex_image_float_019) reduced from 783.75K
> to 290.00K (63.0% reduction)
> Memory usage of 'velocity' (__tex_image_float4_008) increased from 3.06M
> to 3.06M, not using sparse grid. (0% reduction)
>
>
> That’s looking good! The amount of memory saved will heavily depend on how
> values are distributed in a volume, I think in many use cases we will see
> significant savings.
>
> Render time increased from 8:46 to 10:07 (0.86x speed)
>
>
> This we can eventually take a look at in a profiler. Maybe with some
> changes to the memory layout (morton order in tiles?) we can get a better
> cache utilisation from the tiled cache.
>
> While we could convert the offsets into cartesian coordinates, a more
> efficient method would be to simply store the coordinates of the first
> voxel in every tile. While this triples the size of *grid_info*, the
> lookup savings from not having to compute coordinates from the index should
> be worth it.
>
>
> This is something that eventually will need benchmarking. The old
> assumptions of memory vs speed tradeoffs and using lookup tables to save a
> few calculations don’t necessarily hold true any more with modern memory
> architectures, especially on GPUs. A memory lookup through a cache miss can
> take hundreds of cycles, while the processor can execute several additions
> or multiplications in a single cycle.
>
> I think that beginning next week I can start working on creating the
> OpenVDB import function. An easy start would be adding a UI option for it,
> butI will have to read up some more on the background of the problem before
> I can say for certain what will need to be done for this feature.
>
>
> You can also take a look at the work that Luca Rood has done for Tangent
> Animation in their branch:
> https://github.com/tangent-animation/blender278/tree/openvdb_import
>
> Note that this code is still based on Blender 2.78, so it may take a
> little work to get it to run in master. There, OpenVDB import is done as a
> modifier.
>
> Thanks for your work on this project so far! It’s great to see tiled
> memory for volumes being implemented, previously there was lots of memory
> wasted on empty bytes!
>
> -Stefan
>
> --
> Soc-2018-dev mailing list
> Soc-2018-dev at blender.org
> https://lists.blender.org/mailman/listinfo/soc-2018-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/soc-2018-dev/attachments/20180616/f4d48875/attachment.html>