Conversation
luhenry
added a commit
that referenced
this pull request
Oct 2, 2026
Contributor
|
MaterialX 1.39.5's exported MaterialXConfig.cmake calls find_dependency(X11 REQUIRED COMPONENTS Xt) on every non-Apple Unix, regardless of MATERIALX_BUILD_RENDER, so OpenUSD's find_package(MaterialX) fails to configure in the manylinux_2_39_riscv64 image, which has no X11 development packages.
OpenUSD 26.08 moved the default PXR_PYTHON_INSTALL_DIR from lib/python to lib/pythonX.Y/site-packages, so the pxr staging step (which mirrors upstream install_usdex.py and reads <usd>/lib/python/pxr) found no modules and exited on the first one: "pxr.Ar has no _ar binding". Pin the legacy layout of upstream's packman OpenUSD, as build-usd-core.yml already does.
…ures) Group A (14 failures, testMaterialAlgo.py): usdex's own test extra declares usd-validation-nvidia as an open range (py_package.py: >=X,<X+1), which pip resolves to whatever is newest - 1.22.0 as of this run. 1.22.0 added its own built-in UsdShadeShaderSdrCompliance adapter for the native usdShadeValidators:ShaderSdrCompliance validator, which pre-empts usdex's own same-named adapter (registerNativeValidators()'s dedup logic) and reports issues under rule.__name__ == "UsdShadeShaderSdrCompliance" instead of "ShaderSdrCompliance" - the exact name the test fixtures' defaultValidation- IssuePredicates filter on to intentionally swallow their own invented shader ids. Confirmed by diffing the two PyPI wheels (both py3-none-any - not a riscv64 issue) and by repo_tools.toml's own usd_validation_version = "1.21.0" pin, which install_usdex.py --install-test uses exactly but pytest.sh (what this workflow's test step mirrors) does not, since it only installs through the wheel's floating [test] extra. Fix: repin usd-validation-nvidia to the exact repo_tools.toml version as a step after the open-range [test] install, reproducing install_usdex.py's own behavior without changing the published wheel's metadata. Group B (1 failure, testSettings.py): OpenUSD's pxr/base/arch/align.h hardcodes ARCH_CACHE_LINE_SIZE to 64 for every arch but Apple ARM, and these riscv64 runners' real L1 cache line size disagrees, so every subprocess that imports pxr prints an unconditional ArchWarn to stderr (no env var gates it - it's a bare fprintf below Tf's diagnostics layer). This is a non-fatal ARCH_WARNING already noted in gotcha 484 for the build/import path, but testEnableTranscodingSetting is the one test in the suite asserting a subprocess's stderr is byte-for-byte empty rather than matching a regex, so it's the only one this breaks. There's no single "correct" cache-line constant to patch in (riscv64 implementations vary, unlike x86_64), so skip exactly that one test on riscv64 via a new patch against the usd-exchange checkout itself (not OpenUSD), applied by a new "Patch usd-exchange" step. Both fixes only adjust test configuration; the previous "pxr.Ar has no _ar binding" / PXR_PYTHON_INSTALL_DIR fix is unrelated and unaffected.
luhenry
added a commit
that referenced
this pull request
Oct 3, 2026
…, both fixed) Records the evidence for PR #2644's third CI run (37097098270): 14 testMaterialAlgo.py failures from an open-range usd-validation-nvidia test dependency resolving a newer release whose own ShaderSdrCompliance adapter pre-empts usdex's, and 1 testSettings.py failure from OpenUSD's own unconditional cache-line ArchWarn breaking an exact-stderr assertion. Both root-caused and fixed on the PR branch; see .queue.yml's usd-exchange entry for the full writeup. Adds gotcha 629 (open-range test-dependency version drift) and gotcha 630 (OpenUSD's ArchWarn breaking an exact-stderr test) for reuse by other OpenUSD-dependent ports (usd-core, etc).
The third CI run failed the same four testDiagnostics.py tests on every leg (testLevel, testOutputFormatting, testOutputStream, testUtf8Diagnostics). They were already failing in the second run: its 15 failures were 10 testMaterialAlgo + 4 testDiagnostics + 1 testSettings, not 14 + 1, so skipping testEnableTranscodingSetting alone could never have been enough. All five share one cause. Every process that loads libusd_arch on these runners prints OpenUSD's four-line "ArchWarn: ARCH_CACHE_LINE_SIZE != Arch_ObtainCacheLineSize()" block to stderr, and the suite has two helpers that compare a pxr-importing subprocess's stderr exactly: assertOutputStreams() in testDiagnostics.py counts stderr lines, and assertEnvSetting() in testSettings.py asserts an empty stderr for expectedOutputPattern="". Every success-path assertOutputStreams() caller (the four tests above) and the one empty-pattern assertEnvSetting() caller fail. Everything else in both suites that reads stderr is tolerant of extra lines: testFatal uses assertIn/assertLessEqual, the other two testSettings tests use assertRegex (a search), testCore's usd-core conflict tests use assertIn/assertNotIn on strings the warning does not contain, testPxr checks only the return code, and the rtx suite and usdex.test helpers capture nothing (ScopedDiagnosticChecker goes through a Tf delegate, which never sees an fprintf). Instead of skipping each test, drop the narrow testSettings.py patch and fix the warning at its source with a second OpenUSD patch: on riscv64 the comparison has no correct answer. The ISA defines no cache-line size, glibc's riscv sysconf returns the kernel's AT_L1D_CACHEGEOMETRY auxv value, and the kernel fills that from the firmware's cache description (0 when it has none), so whatever align.h hardcodes is wrong on some machines. The warning is printed with a bare fprintf below Tf, so no environment variable can turn it off. It is also user-visible on every import of pxr from the published wheel, not only in the tests. Gate just that comparison on !ARCH_CPU_RISCV; the other Arch_ValidateAssumptions() checks are untouched, and both patches now apply to the OpenUSD checkout from a single step.
luhenry
added a commit
that referenced
this pull request
Oct 4, 2026
python -m venv seeds pip from the interpreter's ensurepip bundle, which is 23.0.1 for cp310 and 24.0 for cp311 in the manylinux image. Both vendor packaging 21.3, whose manylinux arch list has no riscv64, so pip rejected the manylinux_2_39_riscv64 wheel as unsupported on those two legs only.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
usd-exchange3.0.0Compiles the
usdex_core/usdex_rtxC++ libraries and pybind11 bindings, plus the OpenUSD 26.08 runtime (with MaterialX and oneTBB) the wheel bundles. Upstream publishes no riscv64 wheel.Mirrors upstream's repo_man build (
tools/repoman/cmake_build.py,install_usdex.py,py_package.py) and itswhltest suite (tools/pyproject/pytest.sh).Differs from upstream
v26.08built withbuild_usd.py— NVIDIA's packman OpenUSD/MaterialX/oneTBB packages have no riscv64 flavor.PXR_PY_UNDEFINED_DYNAMIC_LOOKUP=ON, so no libpython dependency, as in our usd-core..pyistubs — upstream's stubgen runs through internal repo_man tooling.Matrix: cp310-cp313 — upstream's
requires-pythonis<3.14.Testing
License: Wheel bundles OpenUSD (TOST-1.0), MaterialX and oneTBB (Apache-2.0), with upstream's own notice files.
Patches
0001-Support-riscv64-in-pxr-base-arch.patch—Upstream-Status: To upstream, same patch as usd-core 26.8. Without it OpenUSD'spxr/base/archstops every translation unit with#error "Unsupported architecture". riscv64-only.0002-Skip-the-cache-line-size-assumption-check-on-riscv64.patch—Upstream-Status: To upstream, belongs with 0001. OpenUSD compares its hardcodedARCH_CACHE_LINE_SIZEwithsysconf(_SC_LEVEL1_DCACHE_LINESIZE)on every load oflibusd_archand prints a 4-lineArchWarnto stderr on a mismatch. riscv64 has no architectural cache-line size and Linux reports whatever the firmware describes (0 when it describes none), so the check has no correct answer there. On these runners it printed the warning on everyimport pxr, which failed the 5 tests that compare a subprocess's stderr exactly (4 intestDiagnostics.py, 1 intestSettings.py). riscv64-only.