AndreiBarsan
commented
7 years ago I've implemented this in a basic manner on a separate branch. Seems to work OK on a vanilla map. Takes longer (~4ms vs 2ms for fusion), but that shouldn't be a major issue for our use case.
Remaining tasks:
- [x] Pass cuda-memcheck with full debug on on 100 frames.
- [x] Re-enable instance reconstruction and see if it works OK
- [x] Port and re-enable cosmetic voxel decay
- [x] Pass cuda-memcheck with decay on
- [x] Port and re-enable entry deallocation for single-entry buckets
- [x] Careful visual inspection
- [x] Pass cuda-memcheck
- [x] Add deletion support for any bucket
- [x] Bookkeeping: ensure visible entry list is kept up to date when deleting stuff from multi-element buckets.
- [x] Careful visual inspection
- [x] cuda-memcheck again
- [x] Doublecheck deletion bucket logic
- [x] Cleanup locking code
- [x] Clean up rest of GC code
- [x] Careful visual inspection again
- [x] One last cuda-memcheck
Note: if it takes more than a day in total DROP THIS TASK. Time is limited, and having only cosmetic voxel decay is enough for our purposes.
Despite (slightly) increasing its memory footprint, this would make the engine much more robust (witch cleaner code) to decaying voxel blocks.
Instead of referencing visible entries by their absolute hashTable location, which is brittle once we start moving things around as we're deleting entries, we can keep track of the full coords of the visible blocks, and simply re-look them up in the hash table when necessary, eliminating the problem of stale pointers to deallocated buckets, save for the case where a bucket is completely emptied out, a case which is trivial to detect in the code.