vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions 16 Packages Projects Releases Wiki Activity

llvm21+policy: add NVPTX (future NVIDIA) + document GPU-driver/LLVM strategy

Browse Source 
Per operator: don't forget Intel + virgl, and prepare for future NVIDIA. Intel
(iris/anvil) and virgl need NO LLVM GPU backend (NIR / virtualized) — they stay
in Mesa's driver lists as first-class targets. AMD needs AMDGPU (now); NVIDIA
(future, nouveau/NVK) needs NVPTX. LLVM rebuilds are very expensive, so include
NVPTX now (llvm21: X86;AMDGPU;NVPTX) to avoid an LLVM rebuild when NVIDIA lands.
Documented the vendor->driver->LLVM-backend matrix in the amd64-only policy.
This commit is contained in:
vasilito
2026-07-31 11:05:42 +03:00
parent 5d087d63bc
commit ce8359342c
2 changed files with 34 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
local/AGENTS.md
+20
View File
@@ -579,6 +579,26 @@ Practical consequences:
second CPU platform.
- Build only the amd64 ISO. There are no cross-arch ISOs.
#### GPU driver + LLVM GPU-backend strategy
GPU support is a separate axis from the amd64 CPU platform. Mesa driver lists
(`-Dgallium-drivers`, `-Dvulkan-drivers`) and the LLVM GPU backends
(`LLVM_TARGETS_TO_BUILD` in `recipes/dev/llvm21`) must stay in sync:
| Vendor | Mesa driver(s) | LLVM GPU backend needed? |
|---|---|---|
| AMD | radeonsi (GL), radv (Vulkan) | **AMDGPU** (required) |
| Intel | iris (GL), anvil (Vulkan) | No — NIR + Intel's own compiler |
| virgl | virgl (GL) | No — virtualized (virtio-gpu) |
| software | softpipe/llvmpipe (GL), lavapipe (Vulkan) | X86 (CPU JIT), not a GPU backend |
| NVIDIA *(future)* | nouveau (GL), NVK (Vulkan) | **NVPTX** |
`llvm21` builds `X86;AMDGPU;NVPTX`: X86 = amd64 CPU + software JIT, AMDGPU =
AMD now, NVPTX = **included now** so adding NVIDIA later needs no (very
expensive) LLVM rebuild. Do NOT drop Intel/virgl when touching GPU config —
they need no LLVM backend but are first-class targets. When NVIDIA lands, add
`nouveau`/`nvk` to the Mesa driver lists (LLVM is already ready).
## RELEASE MODEL (FORK — NOT OVERLAY)
Red Bear OS is a FULL FORK, not an overlay. The repository diverges from upstream Redox through local/sources/<comp>/ forks (see "LOCAL FORK SUPREMACY POLICY" below) rather than through per-package overlay patches.
recipes/dev/llvm21/recipe.toml
+14 -9
View File
@@ -69,19 +69,24 @@ set(ENV{CXXFLAGS} "")
NATIVE_EOF
# amd64-only (see local/AGENTS.md): the CPU target is X86 (= amd64/x86_64).
# AMDGPU is the GPU codegen backend Mesa's radeonsi/radv (AMD GPU) drivers
# require via `dependency('llvm', modules: [... amdgpu ...])` — without it the
# host llvm-config the mesa build reads reports amdgpu(missing) and mesa fails
# to configure. AMDGPU is a GPU backend, not a second CPU platform, so it does
# not violate amd64-only.
# GPU codegen backends are a separate axis from the CPU platform and are driven
# by which Mesa drivers we ship:
# - AMDGPU -> radeonsi (GL) + radv (Vulkan), AMD hardware GPUs. Required now:
# Mesa's `dependency('llvm', modules: [... amdgpu ...])` fails without it.
# - NVPTX -> future NVIDIA support (nouveau/NVK). Included NOW so enabling
# NVIDIA later needs no (very expensive) LLVM rebuild.
# - Intel (iris/anvil) and virgl need NO LLVM GPU backend — Intel is NIR-based
# with its own shader compiler and virgl is virtualized; they are enabled via
# Mesa's gallium/vulkan driver lists, not an LLVM target.
# None of these add a second CPU platform, so amd64-only still holds.
case "${ARCH}" in
x86 | x86_64) LLVM_TARGETS_TO_BUILD="X86;AMDGPU";;
aarch64) LLVM_TARGETS_TO_BUILD="AArch64;AMDGPU";;
riscv64gc) LLVM_TARGETS_TO_BUILD="RISCV;AMDGPU";;
x86 | x86_64) LLVM_TARGETS_TO_BUILD="X86;AMDGPU;NVPTX";;
aarch64) LLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;NVPTX";;
riscv64gc) LLVM_TARGETS_TO_BUILD="RISCV;AMDGPU;NVPTX";;
esac
if [ "${COOKBOOK_HOST_SYSROOT}" = "/usr" ]; then
LLVM_TARGETS_TO_BUILD="X86;AMDGPU"
LLVM_TARGETS_TO_BUILD="X86;AMDGPU;NVPTX"
fi
# This just build the LLVM library and tools just enough for Rust, to build the rest of LLVM see