Repository navigation
Update change log for v21.10.01 - #142
Merged
rapids-bot[bot] merged 4 commits intoNov 20, 2021
Merged
Conversation
ajschmidt8
approved these changes
Nov 9, 2021
ajschmidt8
left a comment
ajschmidt8
left a comment
Member
There was a problem hiding this comment.
Approving ops-codeowner file changes
jakirkham
approved these changes
Nov 18, 2021
jakirkham
reviewed
Nov 18, 2021
|
|
||
| # Install dependencies for `cucim.skimage` (assuming that CUDA 11.0 is used for CuPy) | ||
| pip install scipy scikit-image cupy-cuda110==9.0.0b3 | ||
| pip install scipy scikit-image cupy-cuda110 |
Member
There was a problem hiding this comment.
Should we update these as well?
cucim/python/cucim/docs/requirements.txt
Line 21 in 9e346db
Contributor
Author
There was a problem hiding this comment.
good catch!
Updated.
gigony
force-pushed
the
update_changelog_v21.10.01
branch
from
November 20, 2021 19:16
434d805 to
7e60f80
Compare
Member
|
@gpucibot merge |
prateek9623
pushed a commit
to AMD-Ecosystem/hipCIM
that referenced
this pull request
Sep 22, 2026
…6515) (rapidsai#144) Promotes the documentation fixes from AIOSS-6515 (merged as rapidsai#142) from `amd-integration-26.06.00` to `release/26.06.00`. Documentation only — no source or build-system changes. ``` 1bc661e docs: apply doc team review feedback d157d0d docs: simplify the GPU architecture note c58f509 docs: fix install/test instructions found during 26.06 validation ``` `README.md`, `docs/installation/installation.rst`, `scripts/README.md` — +102/-44. Reviewed and approved by the doc team on rapidsai#142. **Please approve only — do not merge from the UI.** This will be fast-forwarded manually so the individual commits are preserved (`release/26.06.00` is at `cebc52ce`, the direct parent of `c58f5098`, so a fast-forward applies cleanly). Refs: AIOSS-6515
prateek9623
added a commit
to AMD-Ecosystem/hipCIM
that referenced
this pull request
Oct 15, 2026
…nstalls (AIOSS-6515) (rapidsai#143) **Complete fix** for the build and coverage issues found while validating the 26.06 install & test instructions (AIOSS-6515). rapidsai#142 is the documentation-only stop-gap for the already-released 26.06 (manual `ROCM_PATH` / `PATH` exports); this PR removes the need for those manual steps. All three supported ROCm layouts were exercised: pip (`rocm[libraries,devel]`), a system-level apt install, and the `rocm/dev-ubuntu-24.04` image. ## 1. ROCm root detection resolved to `/usr` Reported as `CMake Error at CMakeLists.txt:39 (find_package)`. Both `run_amd` and `cucim_resolve_rocm_path()` derived the ROCm root from `dirname(dirname(hipcc))` without resolving symlinks. With a system install `hipcc` is reached through `/usr/bin/hipcc -> /etc/alternatives/hipcc -> /opt/rocm-X.Y.Z/bin/hipcc`, so the root became `/usr` and no HIP package was found. - Resolve `hipcc` to its real path before deriving the root (`readlink -f` / `REALPATH`). - Discard an auto-detected root that contains neither `lib/cmake/hip` nor `bin/hipcc`, falling back to `/opt/rocm`. - An explicit `ROCM_PATH`/`ROCM_HOME` is still honoured exactly as given, so the documented pip flow is unchanged. ## 2. `find_package(HIP)` hidden by a caller-supplied `CMAKE_PREFIX_PATH` The top-level `CMakeLists.txt` only set `CMAKE_PREFIX_PATH` when it was undefined, so a user-provided value replaced the ROCm root entirely. New `cucim_require_hip()` macro in `CuCIMUtils.cmake`: - resolves the ROCm root, **appends** it to `CMAKE_PREFIX_PATH` and de-duplicates, - loads HIP and, when missing, fails with the exact command needed to fix it instead of CMake's generic config-package error. The `cuslide` and `cumed` plugins called `find_package(HIP REQUIRED)` *before* resolving the ROCm root (`cuslide` called it twice), so they configured only when `run_amd` had pre-exported `CMAKE_PREFIX_PATH`. They now use the macro at the right point. ## 3. `cpp_coverage`: `llvm-profdata: command not found`, then `raw profile version mismatch` `cpp_coverage()` searched only `/opt/rocm/llvm/bin`, `/opt/rocm/bin` and `/usr/bin`, then silently fell back to bare command names; `test_cpp_coverage()` had a separate, hardcoded `llvm-*-20` preference. Since the profiles are written by the ROCm clang runtime (clang 22 in ROCm 7.2.x), an older LLVM rejects them with the reported mismatch. Both paths now share `resolve_llvm_tools_()`, which: - detects the ROCm clang major version, - searches the ROCm SDK's own `lib/llvm/bin` first (the pip SDK ships `llvm-profdata`/`llvm-cov`), then `/usr/lib/llvm-<major>/bin`, then `/usr/bin/llvm-*-<major>`, then `PATH`, - warns when the tool is older than the instrumenting clang, - aborts with the `llvm.sh <major>` install command instead of a "command not found", and checks the `llvm-profdata merge` exit status. ## Validation on MI355X (gfx950), ROCm 7.2.3 / clang 22 | Scenario | Before | After | | --- | --- | --- | | CMake configure, system ROCm, no env vars | fails, root detected as `/usr` | `HIP_FOUND=TRUE`, `ROCM_PATH=/opt/rocm-7.2.3` | | CMake configure with `-DCMAKE_PREFIX_PATH=/tmp/nonexistent` | fails | still resolves ROCm and configures | | CMake configure, pip SDK on `PATH`, no env vars | n/a | `ROCM_PATH=.../site-packages/_rocm_sdk_devel` | | `run_amd` ROCm detection, system install | `/usr` | `/opt/rocm-7.2.3` | | `run_amd` ROCm detection, pip SDK | — | `.../_rocm_sdk_devel` | | LLVM tools, pip SDK | not found | `.../_rocm_sdk_devel/lib/llvm/bin/llvm-{profdata,cov}` | | LLVM tools, system ROCm without LLVM installed | `command not found` mid-run | actionable error naming LLVM 22 | `bash -n run_amd` passes. A full `build_local` + `cpp_coverage` run on CI is still worth doing before merge. ## 4. `read_region(..., device="cuda")` needed a manual `LIBVA_DRIVERS_PATH` Reported as `InitVAAPI(drm_node) returned ROCJPEG_STATUS_NOT_INITIALIZED`, surfacing as `rocJpegCreate(backend, 0, &h) returned 'ROCJPEG_STATUS_NOT_INITIALIZED'`. rocJPEG decodes on the VCN engine through VA-API, and libva does not find its backend through the dynamic loader: `vaInitialize()` dlopens `<name>_drv_video.so` from a directory list fixed when libva itself was built (typically `/usr/lib/x86_64-linux-gnu/dri`), which `LD_LIBRARY_PATH` cannot influence. ROCm vendors libva 1.22 and ships the only driver that satisfies it inside its own tree; Ubuntu 24.04's Mesa driver exports `__vaDriverInit_1_20` and is rejected with `has no function __vaDriverInit_1_22`. Users had to export `LIBVA_DRIVERS_PATH` by hand, and the value differs per ROCm layout. `cucim.clara` now sets it during import, before any native extension loads (`_rocm_init._configure_vaapi`), choosing the first directory that actually provides a driver libva can load: 1. `ROCM_PATH` / `ROCM_HOME`, 2. the `_rocm_sdk_*` trees reported by `rocm_sdk.find_libraries("rocjpeg")`, 3. `/opt/rocm/lib/...`, then the versioned `/opt/rocm/core-*/lib/...` layout the apt packages use. Driver naming is probed rather than hardcoded: `LIBVA_DRIVER_NAME` is honoured when set, otherwise `radeonsi` and `amdgpu` are tried (libva's libva-drm map pairs the amdgpu DRM driver with radeonsi, and ROCm's vendored Mesa build answers to both). Runtime-only ROCm wheels ship that backend only as `librocm_sysdeps_gallium_drv_video.so` with no `radeonsi` symlink, so when no conventional name matches, hipCIM names the file explicitly through `LIBVA_DRIVER_NAME`. An existing `LIBVA_DRIVERS_PATH` is never overridden. `run_amd` exports the same value for the C++ tests and benchmarks, which never load Python. ### Validation on MI300X (gfx942), with no VA-API variables preset Both install methods were exercised against three ROCm layouts, in containers built from the documented instructions: | ROCm layout | hipCIM | Detected `LIBVA_DRIVERS_PATH` | `LIBVA_DRIVER_NAME` | `read_region(device="cuda")` | | --- | --- | --- | --- | --- | | pip, `amd-hipcim[rocm]` 10.0.0 (runtime only) | prebuilt wheel | `.../_rocm_sdk_core/lib/rocm_sysdeps/lib` | `librocm_sysdeps_gallium` | `cuda` | | apt `amdrocm10.0-*` | prebuilt wheel | `/opt/rocm/core-10.0/lib/rocm_sysdeps/lib` | unset | `cuda` | | `rocm/dev-ubuntu-24.04:10.0.0-full` | prebuilt wheel | `/opt/rocm/lib/rocm_sysdeps/lib` | unset | `cuda` | | pip, `rocm[libraries,devel,device-gfx942,device-gfx950]` | source build | `.../_rocm_sdk_devel/lib/rocm_sysdeps/lib` | unset | `cuda` | | apt `amdrocm-core-dev10.0-*` | source build | `/opt/rocm/core-10.0/lib/rocm_sysdeps/lib` | unset | `cuda` | | `rocm/dev-ubuntu-24.04:10.0.0-full` | source build | `/opt/rocm/lib/rocm_sysdeps/lib` | unset | `cuda` | Overrides behave as expected: a caller-supplied `LIBVA_DRIVERS_PATH` is kept untouched, and an explicit `LIBVA_DRIVER_NAME` restricts the search to that name only. Test suites on the source builds, with `LIBVA_DRIVERS_PATH` no longer exported by the harness: | ROCm layout | C++ (`run_amd test cpp release`) | Python (`run_amd test_python`) | | --- | --- | --- | | pip SDK | pass, 2636 assertions | 12981 passed, 240 skipped | | apt | pass, 2636 assertions | 12981 passed, 240 skipped | | ROCm dev image | pass, 2636 assertions | — | ## Not included The 4/11154 `cupy ... CURAND_STATUS_LAUNCH_FAILURE` failures are unrelated to the build system and are not reproducible here (MI355X, ROCm 7.2.3, CuPy 14.1.1): the legacy and Generator RNG paths, float32/float64, small and large, all pass. hipCIM only calls `cupy.random`, so this needs the failing node IDs from `junit-cucim.xml` and should be tracked against CuPy-ROCm/hipRAND. Rebased onto `amd-integration-26.06.00`. Refs: AIOSS-6515 Supersedes the workarounds documented in rapidsai#142
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
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.
update-version.shscript to handle links in PyPI README.md