Finding: the ASWF Conan stack ships a single Embree package (4.2.0) on every year, but it cannot be used to build the hdEmbree that the OpenUSD 23.08–25.05 line ships. That line's in-tree hdEmbree targets the embree3 API, while the shipped Conan package provides only the embree4 family.
Detail
- OpenUSD's in-tree hdEmbree selects one Embree family per release.
pxr/imaging/plugin/hdEmbree/context.h is #include <embree3/rtcore.h> on v23.08 / v24.08 / v25.05.01, and #include <embree4/rtcore.h> on v26.03 / v26.08 (source-inspected).
- The Conan embree 4.2.0 package (added to the stack as part of the ci-moonray dependency set, May–Jun 2026) installs only the embree4 family at
/usr/local: embree4/ headers, libembree4.so.4 (+ dev symlink) and cmake/embree-4.2.0. There is no embree3/ header directory and no libembree3* — verified on ci-vfxall 2023–2027.
- Enabling hdEmbree on the 23.08–25.05 lines of the ASWF build therefore fails at compile (
embree3/rtcore.h not found). Only the 26.x lines can build hdEmbree against the shipped package.
- Note this matches Pixar's own
build_usd.py, which pins Embree 3.2.2 for those OpenUSD lines and 4.3.3 for 26.x.
Where it surfaced: the Storm+Embree composite runnable images (usd-render-benchmark:<year>.2) build hdEmbree from the OpenUSD each image ships, deliberately using the Embree shipped in the image (no third-party Embree download). The build fails deterministically on CY2023–2025:
- CY2023: requires embree3, OpenUSD 0.23.8 — build run 34643983129
- CY2024: requires embree3, OpenUSD 0.24.8 — build run 34644248081
- CY2025: requires embree3, OpenUSD 0.25.5 — build run 34644514305
The build workflow (usd-render-benchmark-stack, build-pristine.yml) logs the diagnostic; per-run build logs are on the run artifacts. This also explains why the earlier CY2023–2025 delegate images built their own Embree 3.2.2 for those years rather than using the shipped package.
Upstream candidate: the packaging creates a state where the shipped Embree cannot build hdEmbree against the shipped OpenUSD on 3 of 5 years. Options for upstream: ship an embree3-family package alongside for the ≤25.05 lines, port hdEmbree to the embree4 API on those lines, or document hdEmbree as viable only on 26.x.
Finding: the ASWF Conan stack ships a single Embree package (4.2.0) on every year, but it cannot be used to build the hdEmbree that the OpenUSD 23.08–25.05 line ships. That line's in-tree hdEmbree targets the embree3 API, while the shipped Conan package provides only the embree4 family.
Detail
pxr/imaging/plugin/hdEmbree/context.his#include <embree3/rtcore.h>on v23.08 / v24.08 / v25.05.01, and#include <embree4/rtcore.h>on v26.03 / v26.08 (source-inspected)./usr/local:embree4/headers,libembree4.so.4(+ dev symlink) andcmake/embree-4.2.0. There is noembree3/header directory and nolibembree3*— verified on ci-vfxall 2023–2027.embree3/rtcore.hnot found). Only the 26.x lines can build hdEmbree against the shipped package.build_usd.py, which pins Embree 3.2.2 for those OpenUSD lines and 4.3.3 for 26.x.Where it surfaced: the Storm+Embree composite runnable images (
usd-render-benchmark:<year>.2) build hdEmbree from the OpenUSD each image ships, deliberately using the Embree shipped in the image (no third-party Embree download). The build fails deterministically on CY2023–2025:The build workflow (usd-render-benchmark-stack,
build-pristine.yml) logs the diagnostic; per-run build logs are on the run artifacts. This also explains why the earlier CY2023–2025 delegate images built their own Embree 3.2.2 for those years rather than using the shipped package.Upstream candidate: the packaging creates a state where the shipped Embree cannot build hdEmbree against the shipped OpenUSD on 3 of 5 years. Options for upstream: ship an embree3-family package alongside for the ≤25.05 lines, port hdEmbree to the embree4 API on those lines, or document hdEmbree as viable only on 26.x.