Fixes#2129
CUDA 13.2+ requires LLVM 22.1.2+ for the _NV_RSQRT_SPECIFIER fix.
Assisted-by: Claude Code / sonnet-4.6
Signed-off-by: Larry Gritz <lg@larrygritz.com>
The time it takes to run a full testsuite was slowly creeping up to an
inconvenient time on CI. The most expensive test are the `render-*`
tests. Cut all of their resolutions in half to speed up CI runs.
Update a lot of reference images.
But after updating the ref images we need to fully pass CI (and pass
on my work machine and my personal laptop), I could see that there
were a number of `testsuite/render-*/ref/*.exr` files that did NOT
get updated in this process -- we must conclude that they are old
references that are no longer needed, so I deleted them.
I also noticed that testsuite/render-material-layer had no ref images
updated, and some git investigation reveals that this test that was
added in 2017 was NEVER in testing.cmake and thus never ran in CI
at all. So just remove it.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Analyzing the geomath and trig testsuite entires, each of them had
multiple reference outputs due to small precision differences between
platforms and optimization levels. By printing only 4 digits of
precision (and in one case of an unstable value to pass to tan, just
picking a different value), we are able to collapse those tests to one
reference output each.
only flushes near-zero values, not precision. With the reduced precision every
platform/backend produces identical text, so the four variant references are
removed and a single ref/out.txt remains. The JIT and C++
(OSL_DEBUG_OUTPUT_CPP=3) backends now produce byte-identical output and both
pass against it.
Assisted-by: Claude Code / Claude Opus 4.8
Signed-off-by: Larry Gritz <lg@larrygritz.com>
In main only, i.e. for OSL 1.16 release late in 2026, raise the
minimum OpenImageIO supported to 3.0.
That means that the mostly-2027 version of OSL will support building
against OIIO 3.2 (2027), 3.1 (2026), or 3.0 (2025), which I think is
enough range.
In the process, I shuffled some CI variants around. Removed a couple
variants that used OIIO 2.5, and bumped the job we use for testing a
debug build from being based on 2023 containers to 2026, and the job
we use for checking ABI to 2025.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Some of the translation of type codes to the abbreviations we use
internally for argument type signatures and internal function naming,
like 'f' for float, 'c' for color, etc., were repeated in various
place. This tries to remove some of the duplication.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
- According to ASWF, the technical charter should not be stored in
our repo, but just linked to its canonical ASWF home.
- Security addres in CONTRIBUTING had a bad copy/paste error and
incorrectly had the address for the openimageio security reporting.
- GOVERNANCE did not have the link to the meeting notes.
- README had a bad link, and did not link to the calendar. Spruced
up some related info and the section title.
- Typo fixes
Signed-off-by: Larry Gritz <lg@larrygritz.com>
This commit fixes compilation and runtime errors of the OSL against
specific builds of LLVM 22.
When LLVM is compiled with LLVM_LINK_LLVM_DYLIB=OFF (default value) an
extra set of libraries needs to be used for Clang:
- The clangOptions library is needed because getDriverOptTable() used
from clangFrontend was moved from clangDriver to clangOptions.
- Similarly, printStats() used from clangSema has been moved to
clangAnalysisLifetimeSafety.
This linking error could be reproduced when LLVM is compiled with the
following options:
```
cmake \
-GNinja \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_INCLUDE_TESTS=OFF \
-DLLVM_INCLUDE_EXAMPLES=OFF \
-DLLVM_BUILD_LLVM_C_DYLIB=OFF \
-DLLVM_ENABLE_UNWIND_TABLES=OFF \
-DLLVM_ENABLE_ZSTD=OFF \
-DLLVM_ENABLE_ZLIB=OFF \
-DLLVM_ENABLE_PROJECTS=clang \
-DCMAKE_INSTALL_PREFIX=/opt/local/llvm/22.1.7 \
../llvm
```
A couple of notes:
- The linking issue can not be reproduced when using Homebrew's
LLVM 22 because it uses LLVM_LINK_LLVM_DYLIB=ON. This seems to be
leading to a situation when the linker issue is side-steps because
of the symbols that are pulled by the dynamic LLVM library.
- Passing LLVM_STATIC does not help with this case, since this flag
only affects the way LLVM libraries are handled and does not change
the way Clang libraries are handled:
`llvm-config --libfiles --link-static` does not print any
Clang-related libraries.
Since LLVM version 22 the VFS is to be explicitly created for the
CompilerInstance. Prior to version 22 this was done implicitly by the
LLVM when calling createFileManager(), but now this is no longer the
case, and LLVM has an assertion for it. The createVirtualFileSystem()
with default arguments solves this problem, and initializes
CompilerInstance's VFS the same way how it was done implicitly in the
older versions of LLVM. Without this, compilation of OSO triggers an
assert() in LLVM:
```
Assertion failed: (VFS && "CompilerInstance needs a VFS for creating FileManager"), function
createFileManager, file CompilerInstance.cpp, line 387.
```
It is unclear whether this was causing any actual issue with release
builds of LLVM, but it is better to use the API in the way it is
expected to be used and create the VFS.
Last but not least, this change also fixes the following assert on the
LLVM side when running OSL's test suite on macOS:
```
Assertion failed: ((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) && "Invalid size"), function emitIntValue, file MCStreamer.cpp, line 135.
```
The value that trips on this assert statement comes from the
DW_AT_APPLE_major_runtime_vers that the code in DwarfDebug.cpp, and it
comes from the RuntimeVersion (RV) argument of the createCompileUnit().
This runtime value is supposed to indicate Obj-C runtime version which
is either 1 or 2 (value 2 is for Objective-C 2.0). Passing OSL version
as the runtime version does not fit single byte, and that is why the
assertion trips. This change follows Clang's code which sets the
runtime version to 0 for non-Objective-C languages. It is unclear what
side-effects this change could bring, but it is also a bit strange to
use OSL version for things that distinguish system runtime.
In order to be able to run OSL regression tests with LLVM compiled in
debug mode, LLVM_LINK_LLVM_DYLIB=ON had to be used. Without this, the
following assert in the LLVM triggers upon testrender startup:
```
: CommandLine Error: Option 'openmp-ir-builder-optimistic-attributes' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
```
This is to do with the way how LLVM registers command line arguments.
It uses static variable initialization for this, and having LLVM as a
static library that is pulled via CLang into both oslcomp and oslexec
that are then pulled into testrender causes this situation to happen.
For some reason, it does not happen if LLVM is compiled as static but
release library.
The need of debug versions of OSL and LLVM libraries comes from the
need to compile Blender on Windows in Debug mode, and libraries need
to be compiled with a different CRT ABI.
Tested with the ctest with both LLVM 20 and 22 compiled in release.
With all these changes the test suite passes to the same degree for
LLVM 20 and 22, both Debug and Release. The only failing tests are
related to Python module, and those I did not yet manage to get passing
on a local development machine.
Signed-off-by: Sergey Sharybin <sergey@blender.org>
Adds agent configuration supporting Claude Code, Cursor, GitHub
Copilot, OpenAI Codex, and Opencode. A single AGENTS.md and contents
of .agents subdirectory serve as the canonical source for
instructions, skills, and other things that can be used across
multiple tools.
A script can be invoked by users to do the local setup of links or
references to allow them to use a particular tool:
`.agents/setup-agent TOOL` Currently supported tools by this script
include Claude Code, Codex, Cursor, GitHub Copilot, and OpenCode.
This initial commit includes two skills that I wrote and have used for
the last couple monthly releases: release-notes-update and
prepare-patch-release. I assume that we will add more over time as we
discover tasks that we want to make standard skill automation for.
Assisted-by: Claude Code / claude-sonnet-4-6
The AGENTS.md, Claude skills, and general scheme are entirely from me.
I used Claude to help me establish the setup script for the other
tools I don't happen to use.
This basic structure was first prototyped on OIIO and then copied to
OSL.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
When a parameter is interactive and connected, the connection should
win. OSL was incorrectly treating the interactive trait as taking
precedence, attempting to write into the read-only interactive buffer
during shader execution.
Fixed both single point and batch modes.
---------
Signed-off-by: Chris Hellmuth <chellmuth@gmail.com>
Store the new compile-time complexity metrics that were added by PR
#2085 (but only printed the the log as each group compiles) as fields
on ShaderGroup so they survive after optimization.
Expose them via getattribute(group, "stat:compiled_active_layers")
etc., and extend getstats() to emit a "Shader compilation stats,
post-optimized" section listing min/max/median and a leaderboard with
a ranked top-N list for each metric (controlled by the existing
"stat:rank_groups" option).
Tests: testsuite/compstats/ test covering both the getstats output and
the getattribute keys. Added a testshade --print-group-stats flag for
querying per-group stat keys.
Assisted-by: Claude Code / claude-sonnet-4-6
Signed-off-by: Larry Gritz <lg@larrygritz.com>
We test on 3 Windows runner configurations currently -- Windows 2022
with VS2022, Windows 2025 with VS2022, and Windows 2025 with
VS2026. GitHub says the middle one will go away imminently (actually,
it won't "break", but it will redirect to Windows 2025 with VS2026,
which we already test). So take it out of our lineup, it's just waste.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Alongside the rest of the initialization for subpixel_radiance, an empty MediumStack is initialized. It stores the medium params with pointers in two arrays. One tracks the entry order and the other sorted based on priority. There is a priority handling scheme that will shuffle the incumbent medium pointers to give high priority (lower integer priorities) mediums lower indices. When processing BSDF closures, intersections with MxDielectric or MxGeneralizedSchlick may only be added when priority < current_priority or are both 0 (the precious priority). MediumStack exposes an integrate method that operates on aggregated parameters from all media sharing the same priority as the topmost medium; these aggregated parameters are stored on the stack and updated whenever media are added. A CDF built from these parameters is then sampled to select one of the overlapping media for scattering. At present, only Henyey–Greenstein phase functions are supported, implemented as a BSDF subclass and wraps the implementation in BSDL.
Signed-off-by: Owen O'Malley <theowen@email.com>
docs: Update security instructions to emphasize reporting via GitHub
The security@openshadinglanguage.org is still fine, but we prefer that
true vulnerability reports come via the GitHub security advisory
mechanism. (That makes it easy for us to turn them into CVEs when
needed, among other administrative niceties.)
Signed-off-by: Larry Gritz <lg@larrygritz.com>
This change fixes crashes that could be observed on Ubuntu 24.04.
The crash happens in exception handling after rendering a scene
with OSL shaders.
This seems to be a bug in libgcc which was fixed in 14.3, but
Ubuntu 24.04 is shipped with 14.2. There is a report in the GCC
bug tracker:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119151
Note that this is a runtime dependency, so it doesn't really matter
that a different GCC version was using during compilation as the
EH frames registration happens at runtime.
The easiest solution is to simply disable EH frames registration
in OSL's MemoryManager. This should not affect any runtime exception
unwinding as this MemoryManager is only used during JIT, so all the
EH frames are unregistered from the process when the JIT code is
actually executed.
The issue was originally noticed in Blender, here is the report with
some extra investigation and details:
https://projects.blender.org/blender/blender/issues/156348
Signed-off-by: Sergey Sharybin <sergey@blender.org>
OpenImageIO and OSL have similar CI infrastructure, mostly share a
design of such, and copy the files back and forth to synchronize from
time to time. Turns out it's been a while since the last sync, and a
lot of small improvements have accumulated on the OIIO side.
* Bump our CI workflow externally-hosted actions to the latest versions.
* Use shared-steps workflow for the old aswf container jobs.
* Split some of the steps of the shared-steps workflow into "old" and
"new" in cases where the 2022 ASWF docker containers containers cannot
run the latest actions, only update those to the most recent that are
able for those containers.
* Restore bleeding edge test to pybind11 master -- the reason we locked
it down has since been fixed on the OIIO side.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Periodic re-synchronization of build system components between the two
projects.
dependency_utils.cmake:
* Make dependency report more clear to read.
* Infastructure related to auto-build of missing dependencies, which
we don't yet do in the OSL side, but will eventually institute that
like we did on the OIIO side.
compiler.cmake:
* Warnings about clang versions so old that we no longer test them.
* Imroved ccache finding logic.
* Fix TIME_COMMANDS.
* Turn on CMAKE_EXPORT_COMPIE_COMMANDS to make a compile_commands.json.
* Various other insubstantial changes just to keep the two projects in
sync to make future diffs easier to understand.
gh-win-installdeps.bash:
* Accommodate newer python releases on Windows.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Mostly for conformance with OpenImageIO, since we share so many
scripts and management docmentation. But looking across ASWF project,
they almost all use "docs/" (OSL and OpenVDB were the only outliers).
Signed-off-by: Larry Gritz <lg@larrygritz.com>
I found some places that still referred to the old PDF document in the
repo, but we haven't used that for a while and no longer build it.
Also remove some chunks of the Makefile that used to be responsible
for building the LaTeX docs, since those don't even exist in the repo
any more.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
* When building openexr as a dependency for OSL, there is no need
to build the openexr command line utilities, saving a bit of build
time.
* Fix an error from PR #2074 where we tried to disable nightly CI runs
on forks -- we didn't make the right change to the Windows jobs, so
they were still running.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
fmtlib renamed its "master" branch to "main" yesterday. So our "bleeding edge" test that requests fmt "master" now fails.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
We've discussed AI code assistant policy in multiple TSC meetings,
and on the OpenImageIO slack (technically it was a shared OIIO+OSL
discussion, but we had to pick a single place to have it). We iterated
on the policy document as an OIIO PR, so this PR here in OSL land is
just checking that same document into our repo.
* Duplicate the OIIO document. We will keep them in sync until such
time as the needs of the projects diverge or their communities have
different ideas about what policies to articulate.
* Appropriate references/pointers in supporting documents: README,
CONTRIBUTING, and PULL_REQUEST_TEMPLAGE.
I took the time to diff some of those documents and port other recent
changes from the OIIO side to OSL. These are mostly minor fixes or
improvements in wording, nothing substantive.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
While debugging some CI failures on Windows, I went down some wrong
roads that turned out not to be related to the actual problem... but
nevertheless are improvements I wish to keep. Here they are:
* Attempt to use the install-llvm-action from Windows wasn't able to
work (among other reasons) because we weren't passing along the
llvm_action_ver variable.
* For reasons I never quite understood, the llvm install action works
a lot better on Windows if done before the "build setup" step. So
I just moved that action earlier in the sequence.
* Some status messages about how we are installing LLVM.
* A correction in how we detect and print the pkg_ROOT environment
variable in the log generated by handle_package_notfound.
* Allow LLVM_PATH (set by that action) to be a proper hint for
FindLLVM.cmake.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
A recent change in OIIO main is to check that any auto-built
dependencies have a SHA-1 hash that matches what we think it should be
for that version. That works fine for a fixed version, but if we are
asking for OIIO to build from dependency master/main, as we do from
its "bleeding edge" CI variant, we need to tell it that it's ok to not
match the expected hash by setting
OpenImageIO_DEPENDENCY_BUILD_ALLOW_UNVERIFIED_TAGS=ON. So we need to
do this in the OSL bleeding edge variant, too.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
When using Clang 18<->22 with ld.lld, build fails with:
```
clang++ -Wl,--version-script=.../hidesymbols.map -o lib/liboslcomp.so.1.13.7 ...
ld.lld: error: version script assignment of 'global' to symbol 'test_shade' failed: symbol not defined
```
The issue is that test_shade does not belong to liboslcomp, instead it belongs to libtestshade,
and ld.lld actually checks that and fails. The minimal fix is to remove test_shade from hidesymbols.map,
the slightly better way is to create a separate symbols map for libtestshade.
See also: https://bugs.gentoo.org/929091
Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
* Implement get_albedo() for BSDL imported BSDFs
We forgot to forward the albedo function to BSDL and also to
implement it for the latest MaterialX components added to BSDL
recently. This led to not very good sampling quality.
Signed-off-by: Alejandro Conty <aconty@imageworks.com>
* Incorporate diffuse MaterialX BSDFs to BSDL
This is just a code movement. The implementation was already there. Just
relocated to the BSDL framework the following items:
- burley_diffuse_bsdf
- oren_nayar_diffuse_bsdf
- translucent_bsdf
There are sampling noise differences that require updating the tests,
but otherwise images look identical.
Signed-off-by: Alejandro Conty <aconty@imageworks.com>
* Update testsuite refs and thresholds
Due to the last two commits (BSDL albedo fix and diffuse MTX code
movement) some references had to be updated due to noise differences.
I'm also following the policy of keeping as few refs as possible and
opening the thresholds so different platforms LSB differences are
accepted.
---------
Signed-off-by: Alejandro Conty <aconty@imageworks.com>
* Refactor install_homebrew_deps to match recent changes in the
version that's part of OIIO.
* Exclude building Qt and OpenVDB from the Intel Mac CI variant --
they seem to be hit or miss these days whether it is pre-built, and
if not, makes our CI on that variant take forever. We don't need it,
we test those packages on other platforms, including newer Macs.
* Bump llvm to 18 for the troublesome Intel case.
* Need to make sure OSL sets the OpenImageIO_CI variable also, so that
OIIO, when building, knows it's a CI run.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
We don't test this in CI so it's probably gone undetected for a while,
but there are a few tests that differ slightly for the combination of
ARM-based Mac for debug builds. So check in a few more ref images so
that devs using that platform don't get spurious testsuite failures
for debug builds.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
For a few days now, the Windows CI variants have been almost always
failing due to unexplained inability to curl download the pre-built
LLVM that we stashed on a Google drive, which has worked flawlessly
for over a year.
J.F. Panisset suggested:
> Could be a wild goose chase, but a direction to look in with your
> Windows / curl issue would be SSL certificate verification. Windows
> uses some kind of magic process to update its store of recognized CA
> root certs, but since a Windows runner is a "fresh" Windows VM every
> time, it could be that it is missing an updated cert required to
> verify the https URL you are downloading from (assuming that's using
> a cert anchored to a root CA not in that base WIndows image). I've
> seen issues like that on Windows systems with limited Internet
> access. If you try curl --insecure to (temporarily) bypass
> certificate verification, are you able to download what you need?
And sure enough, adding --insecure clears it right up.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Consolidate sheen implementation from testrender and SPI into a single
BSDL-backed MaterialX lobe (`mtx::SheenLobe`), so sheen behavior is defined
in one place and reused consistently across paths.
- Move sheen logic into BSDL/MTX and wire it through the BSDL closure path
- Replace ad-hoc testrender-side handling with the new BSDL implementation
- Keep Conty/Zeltner mode selection inside the unified sheen lobe
- Update sheen tests and references to validate the new path
- Turn the furnace sheen test into a true energy-conservation check
(sheen layered over white diffuse should converge to flat gray)
AI Disclaimer: AI has been used to code review and bug hunt, but all the
code and fixes have been written by huomans.
Signed-off-by: Alejandro Conty <aconty@imageworks.com>
When compile_report >= 1, report several new post-optimization stats for the shader group:
* Number of active (non-unused) layers
* Maximum connection depth of the shader network (node count along the longest layer-to-layer chain, so a single unconnected node = 1 and a chain A->B->C = 3)
* Number of texture ops (texture, environment, gettextureinfo, texture3d)
* Number of noise ops
Note that these stats (number of layers, texture ops, noise ops) are the total number in the post-optimized shader, but not the number that will be run on any particular execution of the shader. Trivial example: the noise calls may all be inside an "if" statement with a condition that is never true in practice, but that can't be known ahead of time. In the other direction, a loop with noise calls in the body will underestimate how many calls are made in each shader run. So take with a grain of salt -- these stats are related overall shader code complexity, but not necessarily to execution cost.
Coded via pair programming with Claude Code, using the Claude Sonnet 4.6 model.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Intel icc is deprecated and hasn't had a release for a few years. It's
holding us back, both by making us work around an ever growing number
of icc bugs and limitation that will never be fixed, as well as not
allowing us to upgrade minimum versions of certain dependencies,
because icc can't correctly compile newer versions (as an example, it
cannot use a 'fmt' library newer than the oldest we support, 7.0).
So it's time to thank icc for its service and put it on the ice floe
for the polar bears to eat. This is of course in main (future OSL
1.16), and will not be backported to release branches, since we never
stop support of a dependency or toolchain of existing releases. People
requiring icc for whatever reason may keep using OSL 1.15 or older.
We will continue to support and test icx, the fully supported Intel
LLVM-based compiler.
This PR also removes some test reference output that was only needed
for icc.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
The division (xclamped - edge0) / (edge1 - edge0) is not guaranteed
to be exactly 1 for xclamped == edge1 if the backend floating point
math has higher than expected error bounds. Eg. it is common on GPU
backends to use faster but less precise instructions for division.
The modified code is mathematically equivalent and it logically
guarantees the returned value is exactly 1.0 for x > edge1 > edge0.
Signed-off-by: Roeland Schoukens <roelandschoukens@hotmail.com>
Replace the standalone global ErrorHandler with the renderer's own
errhandler() so that error output is properly routed through the
renderer rather than a disconnected handler. This ensures errors during
shading are visible in the same context as the renderer that owns the
ShadingSystem.
Also replace some raw pointers with `new`/`delete` with
std::unique_ptr.
---------
Signed-off-by: Larry Gritz <lg@larrygritz.com>
The ShadingSystem option "llvm_jit_fma" seems to advertise that it
switches between no fused multiply-add (the default, 0), versus
allowing fma to be generated in the JIT.
The underlying LLVM option is actually a 3-way switch about how to
utilized fused ops: Strict (no fused ops), Standard (allow fma but not
other fused ops), or Fast (allow other fused ops when it will speed
things up). Aside: "standard" is really confusing, as one might think
it means original standard IEEE 754 definitions that lacked fma.
These are not the same! We were using llvm_jit_fma to switch between
Standard and Fast, but upon closer examination, we now believe that it
should control a switch between Strict and Standard, and Strict should
be the default.
This seems to directly change the pesky render-microfacet test, which
has always seemed to have an unusual sensitivity to the specific
processor. Hopefully, users will find that across the board, it leads
to their renderers having fewer minor pixel differences from one
platform to another.
Signed-off-by: Larry Gritz <lg@larrygritz.com>
Clamp generalized Schlick F0/F90 to [0, 1] in the MTX Schlick Fresnel
constructor, and clamp the MTX conductor average-Fresnel fit to [0, 1]
to avoid invalid albedo estimates from the approximation.
Also update BSDL bootstrap linking to use Imath::Imath directly instead of
${ARNOLD_IMATH_TARGETS}.
Signed-off-by: Alejandro Conty <aconty@imageworks.com>
Larry Gritz