3.8 KiB
Minutes from 114th OpenVDB TSC meeting, November 23rd, 2021, (EDT)
Attendees: Ken M., Jeff L., Andre P, Nick A., Dan B., Rich J.
Additional Attendees: JT Nelson (Blender), Johannes Meng (Intel), Greg Hurst (United Therapeutics), Kyle Wardlow (United Therapeutics)
Regrets:
Agenda:
- Confirm quorum
- Secretary
- Forum
- Clang 13 MacOS and template instantiation
- PR process discussion
- 8.2 release
- Next meeting
- Confirm quorum
Quorum is present.
- Secretary
Secretary is Richard Jones.
- Forum
From Google Group, there is a question around using different memory allocators and Python (https://groups.google.com/g/openvdb-forum/c/4ULKRCnB8zk). Consensus is that we should advertise Jemalloc in the documentation as it is a good concurrent allocator, which is very important to getting performance with VDB. Some discussion around Jemalloc 5 and reserving large amounts of virtual memory (often causing jobs to be killed by studios if too high), hence why we are still using 3.5. VDB library does not link to any specific custom malloc, this is up to the user when building their executables (vdb binaries do this). Cookbook should be updated to demonstrate how to do this. Could look to add some feedback i.e. a print out that a custom allocator is preferable (after confirming this to be true).
Note for anyone looking to write a custom allocator for VDB: Dreamworks tried for a long time to write own custom allocator for VDB and it wasn't any better than Jemalloc, just added a lot of complicated logic to the library so should probably be avoided.
- Clang 13 MacOS and template instantiation
Ken having issue with missing symbols, Dan (and Greg) unable to reproduce (CI passing on Clang 13), further investigation needed.
- PR process discussion
Nick raises that Point Statistics PR took 6 months to get merged. Discussion of the possibility that trying to create perfect API first time is slowing progress. Suggested solution is to time limit opportunity to scrutinise. Important to not let a delay on reviewing discourage development of useful/sizable additions to the library. The committee recognise that there is a difference the scrutiny required between disjoint new additions (e.g. NanoVDB, AX) and existing tool/API changes. For example, AX and NanoVDB where 'battle-tested' before going into the library. This has obvious advantages (stability/bugs etc.) but can also mean that things like API can be hard to change (if already in use externally). Dan notes that for projects done alongside TSC (e.g. point merging, in progress) can be useful to get consensus on API design before development and testing, Jeff agrees. Nick would like to be more agile/aggressive with improving the library, making more use of deprecation where necessary. Jeff suggests that we make sure to comment code etc. to make it easier to update client code when imposing API changes, but should be willing to change API when a noticable improvement, e.g. recent work on evalMinMax. Ken notes that API stability is very important. Possible solution from Jeff is to allow API changes to new features without deprecation up until it is first released proper, this would allow stuff to go in faster and also be initially tested and improved outside of PR process.
Related to PR process and feedback cycle, Ken will try to push up his vdb_tool to get feedback ASAP. Nick notes that this tool could work closely with vdb_ax and piping vdb data between the two, and that this would be good to test soon.
- 8.2 release
Andre wants 8.2 released. Whilst different branches in git only contain changelogs of version in their history, website should be updated to include all versions.
- Next meeting
Next meeting is in two weeks, December 7th, 2021. 1pm-2pm EST (GMT-5). This will be the last meeting of the 2021.