Academy Software Foundation - Technical Advisory Council (TAC) Meeting - May 15, 2024

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meeting/97880950229?password=81d2940e-c055-43b9-9b5a-6cd7d7090feb

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language (OSL) Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative

Industry Representatives

Jean-Francois Panisset - Visual Effects Society

Non-Voting Attendees

Non-Voting Project and Working Group Representatives

LF Staff

David Morin - Academy Software Foundation
Emily Olin - Academy Software Foundation
John Mertic - The Linux Foundation
Tom Slanda - The Linux Foundation
Yarille Ortiz - The Linux Foundation

Other Attendees

Matthew Cong, OpenVDB
Olga Avramenko, MPC
Deke Kincaid, Digital Domain
Bill Ballew, Dreamworks
JT Nelson, Pasadena Open Source consortium / SoCal Blender group

Antitrust Policy Notice

Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws.

Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

Agenda

Notes

ReadTheDocs
- Most have chimed in to say you have, if you haven’t yet, please let us know. Trying to add them all under LF / releng management in case credentials get lost. Also use project domains for docs, there’s been some conversation in the TAC ticket, we don’t have to do this, but docs.domain.io would be nice to have. Let us know if you want us to move over. Gary: we’re find with docs.openfx.org, will have to do some website update. John: old URL will redirect of course. Action Item: if you haven’t told us you have a ReadTheDocs site, please tell us, and invite releng-aswf as a maintainer.
Open Source Days 2024
- Emily: thanks for all the CFP submissions, most we’ve had for an event, and thanks to volunteers on program committee.
- Sent schedule for virtual town hall / bofs. Town Halls are on zoom week before, bofs will be on July 29th in person only. If you can sign up for a time as soon as possible, want to announce Open Source Days next week, would like to announce virtual town hall and bof schedule at the same time. But most important to pick your time even if not 100% sure of speakers. Reach out to me if none of these times work for you and we’ll figure out something.
- Matthew Low: what about BoFs for non-ASWF projects like Moonray? Emily: use the same form, as of right now BofS are just on one day, but if we need more time, we can add a second day. So we have options if we fill up.
Swift WG
- Scott: can’t comment on the Swift side, but was talking with Furby, we’re thinking of turning these into a single WG which is more than just Swift and Rust, but also C bindings, Python bindings, what can we do to share all the information we have, and continue to build bindings for different languages. Will have a meeting to discuss what this WG should look like, whether it should be a WG or project.
- John: lots of +1s in chat
- Larry (chat): A combined binding group can also do the deep thinking about which language bindings are worth doing and why. Scott: That’s likely going to be one of the goals. The idea is if we decide that there should be support for language XYZ, then that’ll turn into a sub-working group. But, we’ll have to figure out some set of rules to say “there’s enough interest to add this to the list of bindings we support.
- Gary (chat): OpenFX may get some Rust bindings at some point, so we’d love to be in the loop on this. Great idea.
LFX Calendars
- Overall calendar for all ASWF meetings, also a specific per project calendar. Can also set up a vanity subdomain for calendars if you want.
- Can get zoom info. If your group records a meeting, you can access the recording by clicking on a past meeting in the calendar.
- Alexander: can everyone see the recording? John: depends how you set up your recording, can restrict to just your meetings. Alexander: can we get rid of the old calendars? John: yes, we would retire the old calendar. If projects want a transition period that’s OK, or we can turn if off ASAP. Kimball: can we forward / redirect? John: not really, built into the groups.io service. We are working on iCal export, coming shortly. Carol: that would would be the main blocker to retire the old one. Useful to have visibility into all meetings. John: will ask team as to when iCal export will be available, and we’ll turn off old calendars then. Erik: make sure the calendar updates correctly, people have subscriptions to old calendars that don’t update. John: challenge is more calendar clients. Google Calendar only refreshes external iCal calendars every 24h, macOS clients does it quicker. That can be a challenge. Erik: our issues were around time changes. John: LFX side has done work to fix those issues, so should be better.
- John: will be able to color code projects as well in the calendar.
- John: in Project Center can access URL for calendar will forward to it. Also link from ASWF main site
- Larry: is there any reason to not create the vanity URLs for every project? Seems like a good default. John: happy to do this. Larry / Carol: yes, go for it.
- John: will set up calendar redirects for everyone, and will get update as to when iCal export is available.
- Larry: goes along with docs RTD subdomains, having a few “canonical” URLs helps to make things discoverable. Of course redirection from old link is important. But everyone should want to have https://docs.myproject.org
- John: some projects will want to clean up links first
- Larry (chat): calendar.aswf.io is great, I won’t forget that or have to hunt for it.
GPU support on CI runners : OpenVDB / Ken
- FeatureVDB coming into OpenVDB
- CI needs GPU
- When can we have it? We can use internal machines
- JF: GPU builders available available through AWS CodeBuild (OCIO) or new for-pay GitHub Builders. Post in #wg-ci and we can make this work.
nanobind : Ken
- Ken: a Python binding library we’ve started using at NVIDIA, has better support for GPUs
- Matthew Cong:
- VDB Python Bindings : pybind11 to nanobind
- GPU Accelerated Python Bindings for NanoVDB
  - NanovVDB enables GPU support for the VDB data structure
  - Want to enable Python programmers to use GPU-accelerated NanoVDB functionality
  - Example applications for GPU acceleration:
    - Volume queries and sampling
    - Interconversion between sparse and dense representations
    - Mesh to SDF, points to VDB etc
  - Implement bindings with nanobind’s built-in CPU/GPU array exchange support
    - pointsToGrid(ndarray<float, shape<any, 3>,device::cuda> tensor)
  - Allows VDB to be used seamlessly with PyTorch, TensorFlow and other GPU-accelerated frameworks
- Example video of MonkeyMesh moving through sphere with collision detection, all done on GPU.
- A modern and efficient Python binding library akin to Boost.Python and pybind11
- Developed by Wenzel Jakob, same person who created pybind11
  - Faster compile time, smaller binaries (26.3% reduction in the case of OpenVDB), and lower runtime…
- Implications for OpenVDB
  - OpenVDB Python bindings are currently implemented using pybind11
  - Want to support nanoToOpenVDB and openToNanoVDB conversion in Python
  - In order for the underlying C++ object to be portable across two sets of bindings, they need to be built with the same binding library
    - Usual requirements of Python and C++ ABI compatibility for object exchange across dynamic library boundaries also apply
  - Need to also port the OpenVDBPython bindings from Pybind11 to NanoBind
  - Small risk to break external Python bindings, but we think this risk is small
- Proposed Course of Action
  - Move ahead with the port of Python bindings from Pybind11 to NanoBind
    - Introduces a minimal optional dependency on nanobind for OpenVDB
  - Small risk of breaking external Python bindings that translate OpenVDB types at the C++ level
    - Python API for OpenVDB remains identical
    - Change from Boost.Python to pybind11 for OpenVDB was recent and there have been no issues reported
  - Python support for Open to NanoVDB conversion enables workflow acceleration
  - Improved array exchange support makes the ecosystem more modular and improves the reach of VDB for ML frameworks
  - OpenVDB and NanoVDB become trailblazers for GPU accelerated Python-based workflows
- Larry: why is VFX Platform 2022 the earliest version that can be supported? Some projects need to support 2021. Matthew: 2022 upgrades from Python 3.7 to 3.9, and nanobind supports Python 3.8 minimum. Larry: interesting constraint, I know a lot of studios are still on Python 3.7. Other question: pybind11 makes it possible for one project to use the other project’s types in its public API. Would this cause issues with nanobind with interconnected projects? Should all our projects switch? Matthew: it’s more fragile than that, if you have different versions of Pybind11, bindings might not interact. So not sure that just being in the pybind11 ecosystem makes you safe from that if you have different pybind11 versions. Ran into such an issue yesterday, one version of pybind11 aliasing another version. It’s a fragile thing to start with, passing C++ objects between DSOs.
- Kimball: say OpenEXR sticks with pybind11, but want to make a tool that accesses VDBs, what are the implications. Are there automatic conversions between data types so arrays can pass through? Matthew: nanobind generalizes on top of pybind11 which uses the “python buffer protocol”, nanobind uses “dlpack support”, like the “python buffer protocol” extended to support GPU devices. It’s an open source spec, is being / has been adopted as the next generation buffer protocol for Python. Think of it like “numpy extended to the GPU device”. Kimball: if one project switches to nanobind, all of us will have to switch? Matthew: discussion on implications of matching bindings to different C++ types. Kimball: VDB internalized imath types in the past, will you need to create your own version of imath objects if imath doesn’t switch to nanobind? Matthew: there are imath vector types and OpenVDB vector types, could do on the fly conversions using Python type casters. Gordon: does this bring in libraries that would cause issues in more constrained scenarios? Matthew: no hardware dependencies, nanobind is lightweight, always built as a static library which emulates the header-only functionality of pybind11.
- Ken: no red flags? Larry: the opposite, thanks for the presentation, may cause other projects to think about what comes next after pybind11, especially when Python 3.7 requirement goes away.
- Ken: apparently another ASWF project had considered it? Matthew: it was USD (not ASWF). Matthew: yes, discussed in USD WG.
- Eric R: In this context where they’re describing dropped features, what do they mean by embedding: “Multi-intepreter, Embedding: The ability to embed Python in an executable or run several independent Python interpreters in the same process is unsupported. Nanobind caters to bindings only. Multi-interpreter support would require TLS lookups for nanobind data structures, which is undesirable.” Trying to figure out implications of embedding, a lot of apps embed Python interpreters, wasn’t sure if the term “embedding” means what I think it means in this context. Would be a blocker if we can’t use bindings from embeded Python interpreter. Matthew: like embedded Python interpreter in Maya? Larry: you can also use pybind11 to embed the interpreter in your app, when I first heard of nanobind I though that wasn’t there? JC: pybind11 embedding This is what pybind11 documents, nanobind doesn’t support this and likely won’t support it. It means that nanobind doesn’t provide an easy to embed an interpreter, but you can still use the CPython API to achieve the same goal.
- John: will follow up with Matthew and Ken if there are more questions.
- Ken: we promised the TSC we would bring this up and see if there are any loud objections, doesn’t sound like there are any
- Gordon (chat): would be around dependencies: does this change introduce new library or hardware dependencies that might make it harder to use this in more constrained applications?
- Eric R (chat): In this context where they’re describing dropped features, what do they mean by embedding: “Multi-intepreter, Embedding: The ability to embed Python in an executable or run several independent Python interpreters in the same process is unsupported. Nanobind caters to bindings only. Multi-interpreter support would require TLS lookups for nanobind data structures, which is undesirable.”
- Matthew (chat): FWIW, I think Pixar plans to move OpenUSD from Boost::Python to PyBind11, and intentionally not NanoBind b/c it gives up some critical features like custom holders and binding classes w/ multiple inheritance.
- Alexander (chat): USDWG boost::python -> pybind11
- JC (chat): This is what’s not available in nanobind
Dev Days 2024
- Carol: project application form is live, should be easy for projects to fill out. Also link to Dev Days Wiki
- Worked to consolidate info from last year’s Dev Days that were spread between projects. So before you apply, read the project guidelines. We’re also looking on feedback, put together based on last year’s Dev Days. Lists expectations as to what you need to do before (go through Good First Issues, use CLOtributor, choosing a Dev Days Lead, creating a project specific landing page). We want you to think about these requirements before signing up your project for Dev Days. Think about how you want participants to communicate with you during Dev Days so we don’t have to go back and forth as much. We’re going to give projects about a month to look through this and decide if they want to participate. Mid June deadline, may push a bit. We know that July is busy for SIGGRAPH, and August is vacation, and event is in September, so we want to be ahead of the game. Open to feedback / schedule. Next big date will be participant registration at Open Source Days. Keep adding Good First Issues, don’t expect project to have 100% readiness when submitting form, but want at least some of the prep work done.
- John: participant registration will be live before Open Source Days (say 15 July), but big push / launch at Open Source Days
- Link to OCIO to show what a project specific page can look like. OCIO has this on your Wiki, you can have yours wherever you like (Wiki, GitHub)
- Larry: on CLOtributor there are “magic” words to use in project Issues that are critical. You need to follow CLOtributor’s nomenclature when rating issue difficulty in order for it to get picked up. CLOtributor Don’t always love the choices it made, but it’s fine. Carol: we’re requiring the use of labels “good first issue” and “help wanted”. Larry: in CLOtributor docs, they mention something like “mentor available” which is a neat idea. John: that’s a good one, will add to the docs. Carol: want to make sure we don’t create too much work.
- Carol: Sept 25-26, or maybe 26-27? We’ll get the typos fixed!
Operationalizing the TAC Roles plan
- Approved at previous TAC meeting
- We can get this going
  - Want to elect a vice chair, do we want to get this started now?
  - Rotation: rotate at end of the year, or push out later?
- Objections against starting nominations for vice chair? We probably need all the time we can get. Larry: vice chair to Kimball? John: yes. Also for timing when would this run?
- John: we’ll open the call for vice chair, get a few people interested, discuss at next meeting