Repository navigation
Pin the TensorRT-RTX EP 0.5.0 wheel (TensorRT-RTX 1.7.1) - #38
Conversation
- Bump the stock trt-rtx pin (x86_64 and aarch64) from onnxruntime-ep-nv-tensorrt-rtx-cu13 0.4.0 to 0.5.0, which bundles TensorRT-RTX 1.7.1 instead of 1.6.1. Same ABI and minimum ORT. - SONAME links (libtensorrt_rtx.so.1, libtensorrt_onnxparser_rtx.so.1) follow whichever runtime version is vendored instead of a hardcoded 1.6.1, which would have left the 0.5.0 EP unable to load. - The wheel records no version, so a vendored 0.4.0 counted as installed. PluginPackageSpec.VersionMarkerFile names a file only the pinned build ships (libtensorrt_rtx.so.1.7.1); an install without it is replaced, in the installer and in scripts/fetch-ep-plugins.sh. - The patched WSL2 build stays at 0.4.0-wsl2p2 (fix expected upstream in NVIDIA/TensorRT-RTX-EP-ABI#12). It links the stock runtime by SONAME and passes TensorrtRtxWsl2EndToEndTests on 1.7.1 (WSL2, RTX 5070). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 29 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Summary
This PR correctly pins the TensorRT-RTX EP wheel from 0.4.0 to 0.5.0 (TensorRT-RTX 1.7.1), introduces VersionMarkerFile to reliably detect stale 0.4.0 installs, and fixes the previously hardcoded SONAME symlinks to be version-agnostic. The overall approach is sound and the changes are well-structured.
One Blocking Issue
scripts/fetch-ep-plugins.sh — fetch_trt_rtx (x86_64) libcudart symlink is hardcoded (see inline comment). The x86_64 function still checks for the exact filename libcudart.so.13.4.36; if the 0.5.0 wheel ships a different patch (e.g. .37), no libcudart.so.13 symlink is created and the EP cannot load at runtime. The aarch64 sibling function already uses the correct compgen-based dynamic discovery. The same pattern needs to be applied to the x86_64 path. Note that PluginInstaller.cs (the C# equivalent) uses FirstOrDefault for this link which is already version-agnostic.
No Other Blockers
- The new
VersionMarkerFilemechanism and its integration intoIsCurrent/IsVendoredare logically correct. - The dynamic SONAME symlink logic in
CreateRequiredSymlinks(C#) usingLastOrDefaultis correct and future-proof. - SHA-256 hashes and wheel URLs for 0.5.0 are consistent between
scripts/fetch-ep-plugins.shandPluginPackageSpec.cs. - Test coverage for
VersionMarkerFile,CreateRequiredSymlinkswith both 1.6.1 and 1.7.1, and the force-reinstall safety invariant are all present and correct.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
fetch_trt_rtx hardcoded libcudart.so.13.4.36, so a wheel with another CUDA patch version would silently skip the libcudart.so.13 link and the EP would fail to load. Discover it as fetch_trt_rtx_arm64 and the installer do. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
/oc resolve merge conflicts |
|
APIError: Unauthorized: {"result":null,"success":false,"errors":[{"code":10000,"message":"Authentication error"}],"messages":[]} |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Summary
NVIDIA released TensorRT-RTX 1.7. The EP wheel that bundles it,
onnxruntime-ep-nv-tensorrt-rtx-cu130.5.0, was published to PyPI on 2026-10-22. This PR moves the stocktrt-rtxpin to that wheel.manylinux_2_28) and aarch64 (manylinux_2_35) move from 0.4.0 to 0.5.0. The bundled TensorRT-RTX goes from 1.6.1 to 1.7.1. File layout is unchanged, minimum ORT is still 1.24, and the newest glibc symbol needed is still 2.27.libtensorrt_rtx.so.1andlibtensorrt_onnxparser_rtx.so.1were hardcoded to.so.1.6.1, so the 0.5.0 EP couldn't have loaded. They now point at whichever version is in the directory, in bothPluginInstaller.CreateRequiredSymlinksandfetch-ep-plugins.sh.PluginPackageSpec.VersionMarkerFileis set tolibtensorrt_rtx.so.1.7.1. An install without that file is replaced, and the download is verified before the old directory is touched. The fetch script does the same.0.4.0-wsl2p2and not rebuilt, because the fix is expected upstream in fix: WSL2 fallback for GPU device enumeration NVIDIA/TensorRT-RTX-EP-ABI#12. It loads the stock wheel's runtime by its library name (libtensorrt_rtx.so.1), so it now runs on 1.7.1. Verified below.TensorRT-RTX engines don't carry across versions, so any engine cache built under 1.6.1 (
trt_engine_cache_enable) gets rebuilt.Test plan
dotnet build -warnaserrordotnet test: 378/379 pass.ExitCodeTests.Run_MissingRequiredPlugin_Returns3_WithInstallHintalso fails onmain: a vendored MIGraphX plugin can't load on a host without ROCm. Tracked separately.LINML_CATALOG_NETWORK_TESTS=1TensorrtRtxWsl2EndToEndTestson WSL2 with an RTX 5070 (driver 617.42), from a clean root: downloads stock 0.5.0 plus0.4.0-wsl2p2, the GPU is found, and the fixture model returns the expected output.scripts/fetch-ep-plugins.sh trt-rtx-wsl2on a host that had 0.4.0 vendored: replaced it with 0.5.0 and linked to 1.7.1. Running it again is a no-op.🤖 Generated with Claude Code