Repository navigation
fix(clr): ihipLaunchKernel catch all errors, except InvalidSymbol - #8501
Merged
Merged
Conversation
✅ All Policy Checks Passed
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
jiabaxie
changed the title
chrispaquot
approved these changes
Aug 24, 2026
Contributor
|
The only issue is with the rocgdb-cpu job, overriding |
systems-assistant Bot
pushed a commit
to ROCm/clr
that referenced
this pull request
Aug 31, 2026
InvalidSymbol (#8501) ## Motivation <!-- Explain the purpose of this PR and the goals it aims to achieve. --> When KFD Doorbell exhausts, we do not return an error and rather assume the symbol pointer to be correct. We should tell the user that the symbol they queried for is invalid because there is a doorbell exhaustion. ## Technical Details <!-- Explain the changes along with any relevant GitHub links. --> ihipLaunchKernel currently catches 3 known errors. If any are these 3, it will propagate the error up and stop. If not, then it assumes the pointer to be valid even if it cannot validate it. This feature I believe is for backwards compatibility. However, it makes more sense to by default catch all errors except hipInvalidSymbol, as other hipErrors are also valid to propagate. hipInvalidSymbol is for when you cannot find the symbol in the dynamic library, which is for the backwards compatibility case. All other errors, including the one described in the ticket hipErrorNoBinaryForGpu for kfd doorbell exhaustion, should indicate real invalid symbols. ## JIRA ID JIRA ID 27216 <!-- If applicable, mention the JIRA ID resolved by this PR (Example: Resolves SWDEV-12345). --> <!-- Do not post any JIRA links here. --> ROCM-27216 ## Test Plan <!-- Explain any relevant testing done to verify this PR. --> Testing was done on gfx942 machine by attempting to ring doorbell from 300 threads ## Test Result <!-- Briefly summarize test outcomes. --> Before patch: segmentation fault on some threads. After: no segmentation fault. ## Submission Checklist - [x] Look over the contributing guidelines at https://github.com/ROCm/ROCm/blob/develop/CONTRIBUTING.md#pull-requests. [rocm-systems] ROCm/rocm-systems#8501 (commit f82e6dc)
Contributor
TheRock Submodule Bump ActivityNewest first
|
LakshmiKumar23
added a commit
that referenced
this pull request
Sep 30, 2026
…ple relink (#12476) ## Summary On Windows, the exported `rocdecode` CMake target published absolute build-tree paths to the VA import libraries (`rocm_sysdeps_va*.lib`) in its public `INTERFACE_LINK_LIBRARIES`. When a consumer relinks against the installed target — specifically the ctest `--build-and-test` samples, which rebuild on a different machine than the one that produced the artifacts — it inherits those paths, which do not exist there, and the link fails: ``` ninja: error: '.../rocm_sysdeps/lib/rocm_sysdeps_va.lib', needed by 'videodecoderaw.exe', missing and no known rule to make it ``` `rocdecode` is a SHARED library exposing only a C API, so its link dependencies (HIP, the VA import libs, `d3d12`, `dxgi`) are implementation details. This change links them `PRIVATE` on Windows so they stay out of the exported interface. The consumer's own objects reference none of these symbols directly (the sample includes only the public `rocdecode.h` / `rocparser.h` / `roc_bitstream_reader.h` and `hip_runtime.h`, and `find_package`s HIP itself), so nothing needed came through transitive propagation. The change is gated `WIN32`-only; Linux keeps its existing plain (transitive) linking behavior unchanged. ## Impact - **Windows:** VA import-lib paths no longer leak into the exported target; the sample relink on the CI test runner resolves its dependencies independently. - **Linux:** no behavior change. ## Issue Tracking JIRA ID : AICV-285 This is a pre-requisite for **ROCm/TheRock#8501** (Windows rocDecode enablement + CI tests) to pass. TheRock's rocm-systems submodule pointer must be bumped to include this commit before #8501's Windows `Test rocdecode` job can succeed.
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.
Motivation
When KFD Doorbell exhausts, we do not return an error and rather assume the symbol pointer to be correct. We should tell the user that the symbol they queried for is invalid because there is a doorbell exhaustion.
Technical Details
ihipLaunchKernel currently catches 3 known errors. If any are these 3, it will propagate the error up and stop. If not, then it assumes the pointer to be valid even if it cannot validate it. This feature I believe is for backwards compatibility. However, it makes more sense to by default catch all errors except hipInvalidSymbol, as other hipErrors are also valid to propagate. hipInvalidSymbol is for when you cannot find the symbol in the dynamic library, which is for the backwards compatibility case. All other errors, including the one described in the ticket hipErrorNoBinaryForGpu for kfd doorbell exhaustion, should indicate real invalid symbols.
JIRA ID
JIRA ID 27216
ROCM-27216
Test Plan
Testing was done on gfx942 machine by attempting to ring doorbell from 300 threads
Test Result
Before patch: segmentation fault on some threads. After: no segmentation fault.
Submission Checklist