Attendance:

Community:

Discussion:

• VFX reference platform deadline, release needed

  • Mainly for Kimball, still travelling, plan is for him to finish core work, in order to meet deadline for next year we'll have to rush that in. Will follow up with another release with patches as needed.

  • Policy is release by the end of August for inclusion in next year VFX reference platform. Gives some time to adopt it. 

  • Larry: OpenVDB has an extension so we can probably ask for an extension as well.

  • Cary: overdue to report back on intention 

• Python bindings

  • Cary: no comments, so thinking to commit it now. Welcome more feedback on structure. 

• New release of Imath

  • Cary: one egregious typo with version number, 3.11 has version number of 3.10 embedded in it, forgot to change a setting so this needs to be fixed right away. 

  • Cary: pending change to the Imath python binding export line that messed up Alembic

  • Larry: unsure of the right way to fix it

  • Cary: played with it a little, it definitely worked before, broken now (using Alembic as test case). Built with Larry's suggested change but Alembic still did not build. What kind of cmake targets are expected?

  • Larry: when build OIIO against Imath, don't access the target. Not sure which parts of the cmake targets conform ... is it how Alembic is using the target?

• TAC meeting

  • Cary: agreed to set up a meeting on Aug 28 to go over security steps with other project maintainers - dependabot, etc. Fuzz testing is a big item. Could Peter talk about setting up fuzz testing? 

  • Peter: google put us in the fuzz testing originally. 

  • Larry: fuzz testing feels like it's in the "advanced" category. They need to consider whether they are ready for the deluge of reports when it's turned on. Generated a lot of work initially. Release signing and other items that fulfill best practices are more "one and done" items.

  • Cary: presentation will be "here's what it is, copy this workflow", will save fuzz testing for the end of talk since it's more involved. But it is one of the more important steps to take.

  • Rod: CVEs,  bounty?

  • Larry: OIIO has gotten a few. 24/7 fuzz testing will generate more work, projects need to be braced for it. Shake initial things loose with internal project fuzz testing.

  • Peter: fuzz testing only really important if consuming data you might not trust. OpenEXR was really trusting, file format does not support secure model of reading. Talking about it early is good to put on people's radar.

  • Cary: maybe schedule a second session specific to fuzz testing.

  • Peter: fuzz test has a memory limit, lot of working around it.

• Multiple threadpools issue

  • Christina: talked to Edward Lam, SideFX, had an issue with OpenEXR creating its own threadpool, so many threadpools created when using multiple libraries. Wanted a way to define the threadpool OpenEXR should use, share between APIs, had submitted a PR a couple years ago. Ed discussed this with Kimball as well at SIGGRAPH. Kimball mentioned PR had some issues.

  • Larry: on Apple platform they'd love to use the central dispatcher and not use tbb, want to be able to turn it over to the caller.

  • Nick: OpenEXR core was rewritten to move the onus of concurrency to the caller, we should have structured concurrency so for OpenEXR we could make the threadpool go away.

  • Peter: or make it a separate interface, new API call.

  • Nick: passing in a functor rather than imposing a tbb dependency on OpenEXR. 

  • Peter: reason you want to do that is to simplify reading the file

  • Nick: instead of organizing around a threadpool and threadpool abstraction, if structured to take into account more modern concepts outside the C++ standard, rather than taking on task concurrency on our side. So use a std::parallel_for and it just works...

  • Peter: at moment you can only parallelize by reading multiple scanlines at a time. But if do it that way could have parallelization within reading a scanline.

  • Li Ji: doing a lot of benchmarking, relatively old computer, looks like I saturate my IO, want IO faster so try to use multithread, so when ppl talk about multithread, important to keep IO in mind. 

  • Peter: much faster to read compressed files than uncompressed for that reason. People complaining about having so many threadpools, don't really want to have multithreading in OpenEXR at all.

  • Li Ji: with simpler compressors, seems more important to introduce SIMS instead of multithreading. IO-bound, when not using much between compressed file and memory, SIMS is better.

• Li

  • Li Ji: discussed hsi research project using OpenEXR currently. Will discuss further in future meetings. (sorry I missed some part while writing other notes!)