Academy Software Foundation Technical Advisory Council (TAC) Meeting - October 29, 2025

Join the meeting at https://zoom-lfx.platform.linuxfoundation.org/meetings/aswf?view=list&projects=aswf

Voting Representative Attendees

Premier Member Representatives

Project Representatives

Carol Payne - Diversity & Inclusion Working Group Representative, OpenColorIO Representative
Cary Phillips - OpenEXR Representative
Chris Kulla - Open Shading Language Representative
Daniel Greenstein - OpenImageIO Representative
Diego Tavares Da Silva - OpenCue Representative
Jonathan Stone - MaterialX Representative
Ken Museth - OpenVDB Representative
Nick Porcino - Universal Scene Description Working Group Representative
Rachel Rose - Diversity & Inclusion Working Group 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
Yarille Ortiz - The Linux Foundation

Other Attendees

Robin Rowe, Cinepaint
Lee Kerley, Apple
JT Nelson, Pasadena Open Source consortium / SoCal Blender group
Doug Walker, Autodesk / OCIO

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

General Updates
- ORI follow up on Incubation #1167
Annual Review: Zero Trust Working Group #621
Annual Review: Open Shading Language #437

Notes

General Updates
- ORI follow up on Incubation #1167
  - Carol: ORI representative not here today, the ball is in their court. They need a bit of time, they’ve been asked to regroup among themselves and decide. We should check in wih them though, but may take some time.
  - John: do we want to skip the TAC meeting Wednesday before TG holiday? Lots of people skip, let’s skip it. We also have Dec 24, so we should probably skip that as well.
Annual Review: Zero Trust Working Group #621
- Daryll Strauss
- Presentation Slides
- This working group is looking at ways of improving security in ASWF projects by allowing them to operate in zero trust environments. We will develop educational materials and best practices…
- Partitipation: Adobe, Autodesk, Foundry, MovieLabs, Disney, Dreamworks, Google, AWS, would like to see more people on the vendor side.
- Key Achievements in the past year
  - Discussions between software vendors and studios on zero trust requirements
  - Discussion on commercial zero trust solutions that could meet some requirements
  - Identification of identity management in desktop applications, plugins, and rendering as a key issue for users, vendors and studios. Typical browser based authentication for desktop apps is awkward, especially for plugins and render.
  - Initial design of a proxy identity server for desktop
  - In process security reviews of proxy identity server
- The Challenge
  - Apps rely on OS login, which authenticates the process not the user, and doesn’t work well for network services
  - Network services ask the user to login to each service separately which is awkward for the user and often stores credentials locally
  - Apps use API keys which are awkward to setup, long lasting, difficult to track, store credentials, and are difficult to deauthorize
  - Doing OAuth flows in apps is awkward and requires each app to interact with a browser and embed a web server
- Proxy Identity Server
  - Step 1: User Login
    - After logging into their workstation, the user uses the proxy identity server to login to the corporate identity server…
  - Step 2: Identity Request
    - When a desktop application requires user authentication it requests the identity from the proxy identity server. Each desktop application provides a client secret that is used to control access to the identity. The proxy identity server can be configured to pass forward the request to a corporate authorization server to allow fine grained control of which application can request the identity.
  - Step 3: Access Request
    - When the desktop application needs to access a service, they exchange the identity token for the service’s access token. The service must validate the identity token by checking the signature. Once validated the service returns an access token that is used by the desktop application to access the service.
- Proxy Identity Server
  - The Benefits
    - Apps don’t need to deal with SSO flows, just REST calls
    - Users only login once for multiple apps
    - Users can have different versions of their identity (eg to work on different shows)
    - Organizations control which apps can access which services
    - Identity tokens and access tokens can be short lived
- Areas the project could use help on
  - We are moving from early design documents to more formal requirements. Additional review of the designs and requirements would be helpful…
- Feedback on working with ASWF
  - We appreciate the high quality members we have working with our group which would have been more difficult otherwise
- Open Discussion
  - Eric Reineke: have you been able to try these flows with practical examples? Daryll: we are only addressing identity, exchanging an identity with an access token. Eric: that aspect would be working with AWS. Daryll: yes, vendors are interested, they already do similar things.
  - JF: any other industries need this? Daryll: we’ve looked around and haven’t found it. It’s not an issue if you are fully in the SaaS world, has to be a mix of desktop and SaaS apps. Then we have rendering and plugins. The identity token has to live long enough for a render to finish!
  - Michael Min: any considerations around language models and janitor services. There are stories around bad actors being able to ingest tokens into models that act as administrators. Services can then go into admin mode. Is there discussion around these types of issues? Daryll: we stop at the identity part, once you have the token, you can pass it to services. But it’s a tricky problem in general. Jim Helman: could be a good future topic to address. Have discussed challenges around securing agentic AI workflows. Michael: this is not hypothetical. Jim: come join the group!
  - Eric R: this is about tackling workstation identity, then when I launch a job on the farm with my rights, how do I give “operating as” permissions. Daryll: SSO flow will return JWT, proxy identity server will read JWT from env var (for instance), and now your services and plugins can go to identity server. If filesystem still expects POSIX permissions, you will need a mapping service back to UNIX users.
  - Carol: presentation is good. After a year, expectations of a WG is not to produce code. So no pressure to produce a code deliverable, you are doing all the right things, producing documents, working with ASWF projects. Jim: in order to prove this out, can’t just do it on paper. There maybe code for a PoC, but if the PoC looks promising / useful, could eventually become a real version usable in production, then may start a sandbox project.
  - Eric (chat) I think the “workstation-centric” nature and pipeline composed of many applications accessing the same resources aspect our industry might be a bit more unique? I wonder if there are other fields where that happens a lot? Machine Learning researchers? Daryll: agree
Annual Review: Open Shading Language #437
- Larry Gritz, Chris Kuhla (TAC chair) wasn’t able to make it
- Slide Deck
- What is OSL?
  - Shading language for modern production renderers
  - A compiler and efficient runtime for the language
  - Leverages LLVM for execution on CPU and GPU
  - Project just turned 17 years old (first commit 3-sep-2008)
  - ASWF member since 2020
  - Software supporting OSL
    - 3ds Max, Arnold, Blender/Cycles, 3delight, Renderman, V-Ray, Octane, Redshift
  - Studio Renderers
    - Animal Logic’s…
- Recent films
  - Minecraft, Elio, Kpop, Fantastic 4, In your dreams
  - Let us know if it was used on a film you worked on
- What is different about OSL?
  - Shaders can be assembled into networks
    - Networks are evaluated lazily (unused sections are not evaluated)
    - Entire graph is runtime optimized
      - Works across nodes in the shading graph
      - Scales to very large production shaders that have lots of features
      - Optimized can remove 98% of instructions in such cases
    - Automatic differentiation for filtering and bump mapping
      - More accurate and more efficient than finite differences
    - Shaders return closures instead of colors
      - Renderer decides how to integrate the lighting
      - Complex layering can be achieved by building closure trees
- OSL TSC
  - Chris Kulla TSC Chair
  - …
- Code COntributors in the last year
  - 20+ from different organizations
  - Sign of a healthy project
- WHat’s new in OSL 1.14 this year?
  - Released OSL v1.14 in April, 2025 (1.13 was Feb 2024)
  - New Dependency and toolchain minimus
  - Eliminated Boost dependency
  - Support for LLVM 18 (also 19, 20, 21 in patches)
  - Support for OIIO 3.0 (also 3.1 in patches)
  - Support for gcc14 & C++20 (as of 1.14.6.0)
  - Documentation moved to RTD via Read The Docs OSL
  - OptiX now fully tested in CI (as of 1.14.6.0)
    - We would previously frequently break the GPU code path
    - Using the paid runners
  - Texture calls accept “colorspace” optional keyword/argument
  - testrender feature improvements
    - Triangle meshes, displacement, full OptiX support
  - Renderer interface changes
    - ustringhash nearly everywhere (ustring hard on GPU)
  - …
- OSL 1.15 Highlights - Coming soon!
  - Creeping to early spring releases to sync with VFX Platform
  - Raise some dependency minimums
    - Python 3.7 -> 3.9, LLVM 11 -> 14
    - maybe OIIO 2.5 -> 3.0? maybe raise CMake?
  - BSDL library
    - SPI opens sourcing their production BSDFs
  - More improvements for free functions
    - rs_allocate_closure
  - Aiming for full CI testing on Windows
- Future roadmap grab bag
  - Full GPU texture parity with OIIO TextureSystem
  - Dependency auto-build capabilities (similar to OpenImageIO)
  - Continued transition from RendererServices to “free functions” provided as LLVM bitcode
  - Continued GPU improvements
  - Improved guidelines on standard attributes and UI metadata
  - Lightweight oslcomp (new preprocessor, no more libclang)
  - Evolutions to language syntax
  - SPIR-V back end?
- Dev Days
  - Participated in May & Sept 2025 Dev Days
  - No participants in May
  - 3 participants in Sept
    - 1 patch submitted, pending minor revisions
    - 2 participants claimed issued but did not submit a PR
  - Reasons why it’s hard for us
    - Tricky to find “good first issues”
    - C++, LLVM & compiler tech, GPU, rendering -> most parts of OSL require lots of specialized knowledge
    - Lack of developer bandwidth
    - Not good excuses
- How to get involved
  - TSC meetings are every other Thursday at 2PM Pacific Time
    - OSL Calendar Link
  - Slack Channel
    - #openshadinglanguage
  - GitHub
    - OSL Main Web Site
- We’ve had a good year, some time in the past it felt that only a couple of people were contributing, in the last year several substantial contributions from different orgs. So not just one person carrying the project.
- Q&A
  - Eric E: how do the new BSDFs relate to MaterialX? Larry: some are implementations of the BSDFs described by MaterialX, some are not in MaterialX, but we want this to be a “conversation opener”. Working code which can be iterated on. This was a big topic in last year’s tech update, since then are making effort to sync up with MaterialX. We’re trying to make it so OSL is a compliant implementation of what MaterialX specifies.
  - JF: any contributions outside ASWF? Larry: most contributions are from ASWF members, but we do get contributions from major renderers. Not every TSC member is a code contributor, but they are all idea contributors. OSL TSC members often spawn interesting discussion about renderer and shading technology. It’s a like a SIGGRAPH hallway discussion, the right set of people in the room, willing to get into the weeds of specific shader issues to spawn new ideas. Even though SPI does a lot of writing of OSL, we’ve learned a lot. We value the TSC members as idea generators. JF: could be a ASWF blog post? Larry: we get off on very interesting tangents.
  - Michael Min: is there consideration of incorporating SLANG from Nvidia? Eric: not aware of efforts to connect them. SLANG is maybe more of an implementation language like HSLS rather than a shader language. But it is differentiable, and set up for AI training. There’s no connection yet, but an interesting idea. Larry: have been following SLANG, as a successor to HLSL, it could be a no brainer to follow languages getting long in the tooth, but could be different than what we are doing in OSL? But a fresh look at the problem with new ideas, we can learn from it and adopt some new ideas, but not a concerted effort yet.
  - JT (chat) Differential rendering

Next Meeting Agenda

General Updates
Annual Review: OpenTimelineIO #477