Attendees
- TSC Members: Gary Oberbrunner (Dark Star Systems), , John-Paul Smith (Boris FX), Pierre Jasmin (RE:Vision FX), Dennis Adams (Sony), Phil Barrett (Filmlight), Peter Huisma (Assimilate)
- Visitors: Paul Miller (Boris FX), Philippe Jean (Autodesk), Jasmin Roy (Autodesk), Roman Dudek (SGO Mistika), Mikki Wells (Boris FX), Scott Wilson
Minutes
Meeting called to order at 11:05am EST
Organizational Matters
- The Association as filed a motion to be dissolved; we are in a 2 month waiting period before it is closed but nothing more needs to be done.
- All Association funds have been donated to ASWF.
- Website: no action since last time. Gary will ping John Mertic to see what we need to do next – fill out website form?
- Pierre asked if we have a shared document repository like dropbox or github available from ASWF or the Linux Foundation. Gary will ask John M.
- Gary will ask John about github migration – we are ready for that.
- Mailing lists have all been migrated over to ASWF.
Technical Matters
Overlay Draw Suite:
- This is in https://github.com/ofxa/openfx/pull/97
- Paul will review, add doc, & implement (in progress)
- Question was raised: what about custom param drawing? (As opposed to image overlays)
- Red Giant does this, says Pierre
- Group decided not to try to support custom params with this new suite yet - too many unknowns
- Action items: Pierre will talk w/ Red Giant, Phil will write some text describing current limitations to be included in the header(s)
GPU:
- Progress update on adding the new GPU image-transfer extensions: OpenCL, CUDA, Metal, etc.
- Initial version with new properties (mistakenly) added directly to main in https://github.com/ofxa/openfx/commit/aad9e0c43
- Who's using which GPU transfer modes today?
- Sony: OpenCL & OpenGL
- Baselight: OpenGL, about to release CUDA & Metal
- Mistika: OpenGL (would use OpenCL but not today)
- RE:Vision: OpenCL, or OpenGL sometimes (in-house Vulkan & Metal, unreleased)
- Paul: OpenGL and OpenCL native (plugin side; host coming)
- Resolve: CUDA & Metal
- Sapphire: BMD CUDA extension
- Assimilate: OpenCL (& OpenGL)
- Pierre asks: should these new image extensions support the same features as the OpenGL extension – specifically, what about GPU/CPU opt-out and fallback, and error handling?
- Phil: both host & plugin declare support, then host decides which it'll send, so there's no support for CPU opt-out
- Who will work on adding support for these features?
- Dennis will implement plugin & host (Paul too); he'll work on plugins being able to opt out
- Sounds like a mini-project or subcommittee
- CPU fallback and/or opt-out
- Error handling
- Documentation
- Need official examples (can get from BMD examples, but may need copyright clearance)
- Jasmin Roy, Autodesk:
- Interested in direct Vulkan support in OpenFX
- Substance Vulkan lib is now in Flame
- They have a prototype API working; not perfect yet but functional
- Shares device, queues, etc.
- Plugin has to own its own shaders & manage mem
- Would like to move to host-side buffer/texture management, but current version works OK
- There are something like 5 objects to be sent to the plugin, but not too complex
- Synchronization: each render request has to be synchronized (flush device) -- even with sync it's still pretty fast
- Alternate possibility: provide command queues to plugin from host (but not how it works now)
- Phil: other GPUs pass queue and don't synchronize; would be best to stick to that (Jasmin agrees)
- Working on Mac in MoltenVK as well as Linux
- "More complicated than Metal but totally doable"
- Pierre says RE:Vision might be willing to help test this from plugins, but would need an example to work from
- Dennis: we should ship more examples in general, especially for new features -- what about host support?
- Maybe start w/ BMD example and try porting that to Vulkan?
- Would need copyright clearance to ship them but could use internally
- Dennis suggests host could have functions to allocate & cache buffers & textures
- This could be useful for CPU as well (compute cache style)
- Peter: if we add more than what's in Resolve, will Resolve take up the additional features? If not, are we wasting our time?
- There are other OFX hosts, so perhaps not
- Pierre will ask Resolve folks if they would implement a standard version of their suite (with new features/methods)
Color handling progress report:
- Will be based on OpenColorIO (OCIO)
- JP submitted OCIO extension PR, WIP, Phil has provided feedback
- They will continue on that a few more iterations before it'll be ready
- Currently it's used between hosts & plugins that both use OCIO; may need more work if one side isn't using OCIO
- What about an ACES host or plugin (without OCIO support)?
- Maybe a minimal OCIO config just to support plugins that need it?
- API sends a reference to a disk file and some strings rather than a complete OCIO config – those are large
- Need OCIO props on output clip (not there yet)
- What about transitions – what if each clip had a different color space? That's a bit pathological, but we should define behavior
Rust bindings: discussion proposed by Scott Wilson, but he had audio problems and had to drop off
- Discussion deferred til next meeting
- Gary will check out C++ wrapper: does it still build?
Meeting adjourned 12:15pm EST