[Soc-2018-dev] Changes needed for CUDA to handle Sparse Grids

Brecht Van Lommel brechtvanlommel at gmail.com
Wed Jun 6 19:29:14 CEST 2018


I was thinking we could use an 8x8x9 grid, which wouldn't was as much
memory. Unfortunately it seems there is a CUDA texture size limit of
16384x16384x16384, and we'd hit that quite quickly if we use only one
dimension..

I'm not sure what the best solution is then, since 1.5x more memory usage
is a lot. There's interesting ideas here but it gets quite complicated:
https://developer.nvidia.com/sites/default/files/akamai/designworks/docs/GVDB_TechnicalTalk_Siggraph2016.pdf

What I suggest to do is to just store 8x8x8 grids and not take advantage of
linear interpolation of tex3D() for now, to avoid getting side tracked too
much. So for sparse grids replacing each tex3D() with 8 voxel lookups with
closest interpolation. You can still do all the changes to remove
SparseTile.

Does that make sense?

Regards,
Brecht.



On Wed, Jun 6, 2018 at 7:04 PM, Geraldine Chua <chua.gsk at gmail.com> wrote:

> Hi all,
>
> So this mailing list seems to be more for the weekly reports, but I think
> it's easier to talk about planning in email, especially since it's diffcult
> to align schedules and I think we can have more detailed discussions this
> way. Please don't hesitate to comment if there are any glaring flaws or
> things I need to take into account :P
>
> First of all, after Brecht has told me about how CUDA does interpolation,
> I do not think the current approach of having a dedicated SparseTile struct
> is viable anymore. The sparse grid will need to be changed to a flat array
> of floats/float4s/etc. Changing this and all dependant code shouldn't be
> difficult or take too long, and will actually make some parts of the code
> much cleaner.
>
> So now dense grids are transformed from some X x Y x Z grid to a long,
> thin N x TILE_SIZE x TILE_SIZE sparse grid, where N is the number of active
> tiles * TILE_SIZE. Because of this configuration, neighbor tiles in the
> sparse grid are not necessarily neighbor tiles in the real image, so there
> must be a way of getting the real voxel neighbors since they are needed for
> interpolating at the boundaries of a tile.
>
> The way suggested by Brecht (or at least my interpretation of his
> suggestion, I might be wrong) is to give every tile a pad containing its
> real neighbors. Thus, each "tile", instead of being an 8x8x8 grid for
> example, is now a 9x9x9 grid or larger, depending on how wide a sample the
> interpolation requires. There is quite a lot of voxel duplication using
> this method though, and it will have a large impact on the memory usage,
> since for example, just a 9x9x9 grid is already around 1.5x larger than an
> 8x8x8 grid.
>
> If any of this doesn't seem right or there is a better approach or there
> are other functions I need to take into account that will require sparse
> lookup support, I would really appreciate your comments :)
>
> Best regards,
> Geraldine
>
>
> --
> 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/20180606/78b731fb/attachment.html>


More information about the Soc-2018-dev mailing list