HIP documentation update for clarity on definition

[saadrahim]

Associated JIRA ticket number/Github issue number

What type of PR is this? (check all applicable)

• Refactor
• Feature
• Bug Fix
• Optimization
• Documentation Update
• Continuous Integration

What were the changes?

Drop references to our competitor's GPUs

Why are these changes needed?

Clarity

Updated CHANGELOG?

• Yes
• No, Does not apply to this PR.

Added/Updated documentation?

• Yes
• No, Does not apply to this PR.

Additional Checks

• I have added tests relevant to the introduced functionality, and the unit tests are passing locally.
• Any dependent changes have been merged.

[kiwigitops]

Reading this as a downstream user, one thing worth pausing on: the original wording — "HIP is a C++ runtime API and kernel language that lets you create portable applications for AMD and NVIDIA GPUs from a single source code" — describes a real, documented capability of HIP today (HIP code compiles via hipcc to ROCm on AMD GPUs and via the NVIDIA back-end to CUDA on NVIDIA GPUs, see e.g. HIP Programming Guide → Portable code design). Dropping it leaves the new copy reading as if HIP were AMD-only, which doesn't match the project's design or the hipcc build matrix.

A couple of clarifying questions before this lands:

1. Is the NVIDIA back-end being deprecated as part of a broader policy change? If yes, that's worth calling out explicitly (with a deprecation note + timeline) so users currently relying on HIP-as-portability-layer aren't surprised. If no, removing the portability framing without replacement may understate the project's scope.
2. what_is_hip.rst also loses the "thin API with little or no performance impact over coding directly in NVIDIA CUDA or AMD ROCm" line and the hip.svg figure showing the dual back-end. Was that intentional, or fallout from the broader trim?
3. Would re-framing rather than deleting work — e.g. "HIP is a C++ runtime API and kernel language for AMD GPUs, with a CUDA back-end available for portability to NVIDIA hardware" — keep the technical accuracy while still centering AMD in the lede?

Not blocking — just flagging because the wording shift is more user-facing than a pure cleanup and I think a follow-up reader might be confused. Happy to defer to whatever the docs team has decided.