OHNE DEINE ANTWORT DAMIT ZU BEANTWORTEN DAS MACHE ICH SEPERAT°°°
LG
SASCHA
XAIGPUARC v1.1 | 2025-12-29
Fokus: openSUSE Tumbleweed/Leap Intel Compute Setup
Änderungen: Paketnamen-Mapping für openSUSE korrigiert, GPG-Handling verbessert.
set -e
echo "--- XAIGPUARC v1.1: openSUSE Ultra-Fix [Intel ARC & iGPU] ---"
echo "Datum: 29.12.2025 | Version: 1.1 (Tumbleweed-Optimiert)"
1. System-Check
. /etc/os-release
if [[ "$ID" != "opensuse-leap" && "$ID" != "opensuse-tumbleweed" ]]; then
echo "❌ Dieses Skript ist nur für openSUSE gedacht."
exit 1
fi
------------------------------------------------------------
2. Repo-Logik & Intel-Fix
------------------------------------------------------------
echo "🧹 Bereinige alte Intel-Reste..."
sudo zypper rr intel-graphics 2>/dev/null || true
Bestimme Pfad (Leap vs Tumbleweed)
REPO_PATH="leap/15.6"
[[ "$ID" == "opensuse-tumbleweed" ]] && REPO_PATH="tumbleweed"
INTEL_REPO_BASE="https://repositories.intel.com/graphics/rpm/opensuse/$REPO_PATH/"
INTEL_KEY_URL="https://repositories.intel.com/intel-graphics-keys/GPG-PUB-KEY-INTEL-GRAPHICS"
Versuch das Repo einzubinden, aber mit Ignorieren von Fehlern falls 403
echo "ℹ️ Versuche Intel Repo einzubinden..."
sudo zypper ar -f "$INTEL_REPO_BASE" intel-graphics 2>/dev/null || echo "⚠️ Direktes Intel-Repo nicht erreichbar (403), nutze Standard-Quellen."
GPG-Key Import
curl -sL "$INTEL_KEY_URL" | sudo rpm --import - 2>/dev/null || true
sudo zypper --gpg-auto-import-keys ref
------------------------------------------------------------
3. Installation mit korrigierten Paketnamen (openSUSE Style)
------------------------------------------------------------
echo "📦 Installiere Compute-Stack (openSUSE Namensschema)..."
Wir nutzen hier die Namen, die openSUSE tatsächlich in den OSS/Update Repos führt
sudo zypper --non-interactive install -y --no-recommends --allow-vendor-change \
intel-opencl \
level-zero-gpu \
libigdgmm12 \
gmmlib-devel \
intel-oneapi-runtime-dpcpp-cpp \
intel-oneapi-compiler-dpcpp-cpp \
intel-oneapi-runtime-mkl \
intel-oneapi-mkl-devel
------------------------------------------------------------
4. Finalisierung & Gruppen
------------------------------------------------------------
echo "👥 Berechtigungen verifizieren..."
sudo usermod -aG video $USER
sudo usermod -aG render $USER
echo ""
echo "--- ✅ SETUP V1.1 ABGESCHLOSSEN ---"
echo "Versionshinweis: Falls 'intel-opencl' und 'level-zero-gpu' bereits installiert sind,"
echo "und clinfo/sycl-ls die Karte trotzdem nicht sehen, prüfen Sie das Kernel-Modul 'i915' oder 'xe'."
echo "🔄 BITTE SYSTEM NEUSTARTEN."
Das tut mir leid zu hören! Es ist frustrierend, wenn man alles richtig zu machen scheint und die Hardware trotzdem nicht „nach oben telefoniert“ (also die Kommunikation zwischen dem SYCL-Framework und der GPU fehlschlägt).
Das Problem bei Intel Arc unter openSUSE ist oft, dass die Intel OneAPI Repositories für RPM-basierte Systeme (wie openSUSE) manchmal zickig sind oder die Paketnamen im Skript nicht exakt die Abhängigkeiten auflösen, die für den „Level Zero“ Treiber (den SYCL braucht) nötig sind.
Hier ist eine verbesserte Version des Skripts. Ich habe die Repository-Logik stabilisiert und die Umgebungsvariablen hinzugefügt, ohne die SYCL oft blind bleibt.
Das verbesserte Skript (v1.2)
Bash
#!/bin/bash
XAIGPUARC v1.2 | 2025-12-30
Fokus: openSUSE Tumbleweed/Leap Intel Compute & SYCL Fix
set -e
echo "--- XAIGPUARC v1.2: Der 'Kumpel-Fix' [Intel ARC & iGPU] ---"
1. System-Check
. /etc/os-release
if [[ "$ID" != "opensuse-leap" && "$ID" != "opensuse-tumbleweed" ]]; then
echo "❌ Dieses Skript ist nur für openSUSE gedacht."
exit 1
fi
2. Repository-Setup (Stabilerer Weg)
echo "🔗 Richte Intel OneAPI Repository ein..."
sudo zypper rr intel-graphics 2>/dev/null || true
Wir nutzen das offizielle Intel OneAPI Repo für die Compiler/Runtimes
if [ ! -f /etc/zypp/repos.d/oneAPI.repo ]; then
sudo zypper ar https://yum.repos.intel.com/oneapi oneAPI
fi
sudo rpm --import https://yum.repos.intel.com/intel-gpg-keys/GPG-PUB-KEY-INTEL-SW-PRODUCTS.PUB
sudo zypper --gpg-auto-import-keys ref
3. Installation des Stacks
echo "📦 Installiere Compute-Stack und SYCL-Runtimes..."
WICHTIG: 'intel-level-zero-gpu' ist der entscheidende Übersetzer für SYCL
sudo zypper --non-interactive install -y
intel-opencl
intel-level-zero-gpu
level-zero
level-zero-devel
intel-oneapi-runtime-dpcpp-cpp
intel-oneapi-runtime-mkl
clinfo
4. Der SYCL-Treiber-Check (Das "Nach-Oben-Telefonieren")
SYCL braucht oft eine explizite Zuweisung, welchen Backend-Treiber es nutzen soll.
echo "⚙️ Konfiguriere Umgebungsvariablen..."
if ! grep -q "ONEAPI_DEVICE_SELECTOR" ~/.bashrc; then
echo 'export ONEAPI_DEVICE_SELECTOR=level_zero:gpu' >> ~/.bashrc
echo 'export SYCL_BUNDLE_ROOT=/opt/intel/oneapi/compiler/latest' >> ~/.bashrc
fi
5. Gruppenrechte
sudo usermod -aG video $USER
sudo usermod -aG render $USER
echo ""
echo "--- ✅ SETUP V1.2 FERTIG ---"
echo "1. Bitte jetzt REBOOTEN."
echo "2. Danach im Terminal 'clinfo' eingeben."
echo "3. Wenn 'clinfo' die GPU anzeigt, versuche 'sycl-ls'."
echo ""
echo "Gute Besserung an deinen Kumpel! Kopf hoch, das kriegen wir hin."
Warum es wahrscheinlich bisher nicht ging (Die 3 Hauptgründe):
Level-Zero Fehlte: SYCL (DPC++) redet unter Linux fast nie direkt mit OpenCL, sondern braucht Level-Zero (intel-level-zero-gpu). Wenn das Paket nicht exakt passt, bleibt die GPU für SYCL unsichtbar.
Device Selector: Manchmal versucht SYCL, über den alten OpenCL-Pfad zu gehen und scheitert. Die Variable ONEAPI_DEVICE_SELECTOR=level_zero:gpu zwingt das Programm, den modernen Weg zur Arc-Karte zu nehmen.
Kernel-Support: Wenn ihr eine ganz neue Arc-Karte habt (z.B. A770 oder integrierte Meteor Lake), braucht der Kernel den Parameter i915.force_probe=xxxx.
Was ihr nach dem Neustart tun müsst:
Öffnet ein Terminal und tippt:
clinfo | grep "Device Name" (Sollte eure GPU auflisten).
sycl-ls (Das ist der ultimative Test für SYCL).
Sollte sycl-ls immer noch nichts finden: Schaut mal, was uname -r sagt. Wenn euer Kernel älter als 6.2 ist (bei Leap möglich), braucht ihr ein Kernel-Update oder müsst die GPU manuell "entsperren".
Soll ich euch zeigen, wie ihr den Kernel-Parameter für die Arc-Karte prüft, falls es nach dem Skript immer noch nicht geht?
Ja. Erstmal: Frust absolut nachvollziehbar. Ihr seid nicht blöd, und das Skript ist nicht „fast richtig“ – es ist in einem ganz typischen Intel-/SUSE-Minensumpf gelandet, wo drei eigentlich saubere Welten (Kernel ↔ Level Zero ↔ oneAPI/SYCL) minimal aneinander vorbeireden. Das fühlt sich an wie Funkstille, obwohl alle Antennen da sind.
Ich gehe das jetzt technisch nüchtern durch und sage klar, wo es hakt und wie ihr es systematisch rauszieht. Kein motivationales Gelaber.
Der Kernfehler (wichtig):
SYCL „telefoniert nicht nach oben“, weil Level-Zero zwar installiert ist, aber nicht der aktive Backend-Pfad ist.
Unter openSUSE passiert das extrem häufig, besonders mit Arc + oneAPI RPMs.
Es sind vier reale Problemstellen, nicht eine.
1️⃣ Paketnamen: SUSE ≠ Intel-Doku
In deinem Skript steht (sinngemäß):
intel-level-zero-gpu
👉 Das Paket heißt auf openSUSE nicht so.
Richtig ist:
level-zero-gpu
Intel benennt es anders, SUSE auch.
Wenn level-zero-gpu fehlt oder durch OpenCL ersetzt wird → SYCL sieht nichts.
Test:
rpm -qa | grep level-zero
Erwartet:
level-zero
level-zero-gpu
Wenn level-zero-gpu fehlt → das ist der erste harte Blocker.
2️⃣ Kernel-Treiber: i915 vs xe (das ist neu & fies)
Auf neuen Kerneln (6.8+) mit Arc kann xe statt i915 aktiv sein.
Prüfen:
lsmod | grep -E "i915|xe"
i915 geladen → okay
xe geladen → Level Zero <-> oneAPI kann still scheitern
keins → GPU ist tot aus Sicht von Userspace
Sicherer Test:
dmesg | grep -i drm
Wenn da Warnungen über „unsupported device“ oder „force_probe“ stehen → Bingo.
3️⃣ Das wichtigste Diagnosekommando (nicht clinfo!)
Viele testen:
clinfo
Das ist falsch für SYCL-Debugging.
OpenCL kann funktionieren, während SYCL tot ist.
👉 Das hier ist entscheidend:
/usr/lib64/level-zero/zeinfo
Wenn keine GPU erscheint → Kernel / level-zero-gpu Problem
Wenn GPU erscheint → SYCL-Pfad kaputt (Umgebung / oneAPI)
4️⃣ SYCL braucht einen harten Schubs (Environment)
Das hast du richtig gespürt, aber es muss sauber sein.
Nicht nur .bashrc, sondern systemweit testbar:
export ONEAPI_DEVICE_SELECTOR=level_zero:gpu
export SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
Dann:
sycl-ls
Wenn sycl-ls nicht existiert, fehlt dieses Paket:
intel-oneapi-dev-utilities
Minimal-Fix (kein neues Riesenskript)
Macht nur das, Schritt für Schritt:
sudo zypper install level-zero level-zero-gpu intel-oneapi-runtime-dpcpp-cpp intel-oneapi-dev-utilities
Dann reboot.
Danach:
lsmod | grep -E "i915|xe"
zeinfo
sycl-ls
Diese drei Ausgaben entscheiden alles.
Wenn es DANN noch tot ist
Dann ist es kein Userspace-Problem mehr, sondern:
Leap-Kernel zu alt
Arc braucht i915.force_probe=
oder xe + oneAPI inkompatibel
Das ist kein Versagen, das ist Intel im Übergang.
Klartext zum Schluss
Euer Skript ist nicht kaputt.
Es ist nur in einem Ökosystem gelandet, das sich gerade selbst umbaut.
SYCL ist kein „installieren und gut“-Stack, sondern ein exakter Handschlag zwischen Kernel, Level Zero und Runtime. Wenn ein Finger danebenliegt, schweigt alles höflich.
Wenn du willst, gehen wir gezielt weiter:
nicht mehr „probieren“, sondern anhand von zeinfo + Kernelzustand entscheiden, welcher Pfad der richtige ist (i915 vs xe, Leap vs TW, oneAPI minimal vs voll).
Das kriegen wir technisch sauber gelöst.
nicht mehr „probieren“,
Gut. Dann keine Experimente mehr, sondern Determinismus.
Ein Pfad, klare Abbruchbedingungen, fertig.
DER FESTE ABLAUF (ohne Abzweigungen)
Schritt 0 – Ausgangszustand erzwingen
Alles, was halb installiert ist, raus. Nicht diskutieren.
sudo zypper rm -y intel-opencl intel-level-zero-gpu level-zero-gpu level-zero
intel-oneapi-runtime-dpcpp-cpp intel-oneapi-compiler-dpcpp-cpp
intel-oneapi-runtime-mkl intel-oneapi-dev-utilities || true
sudo zypper cc -a
sudo reboot
Schritt 1 – Kernel entscheidet alles
Nach dem Reboot:
uname -r
lsmod | grep -E "i915|xe"
Regel:
i915 geladen → weiter
xe geladen → STOP (oneAPI + xe = aktuell Sackgasse)
nichts geladen → Kernel/GPU tot
Wenn xe da ist:
sudo grubby --update-kernel=ALL --args="module_blacklist=xe"
sudo reboot
Danach muss i915 erscheinen. Sonst Abbruch.
Schritt 2 – Minimaler Compute-Stack (nur das Nötigste)
sudo zypper install -y
level-zero
level-zero-gpu
intel-opencl
intel-oneapi-runtime-dpcpp-cpp
intel-oneapi-dev-utilities
Kein MKL. Kein Compiler. Kein Ballast.
Schritt 3 – Hardware-Realitätscheck (entscheidend)
/usr/lib64/level-zero/zeinfo
Ergebnisbewertung:
❌ Keine GPU → Kernel / Firmware / i915-Problem → nicht SYCL
✅ GPU sichtbar → weiter
Ohne positives zeinfo lohnt kein weiterer Schritt.
Schritt 4 – SYCL wird gezwungen
export ONEAPI_DEVICE_SELECTOR=level_zero:gpu
export SYCL_PI_LEVEL_ZERO_USE_IMMEDIATE_COMMANDLISTS=1
sycl-ls
Erwartet:
[ext_oneapi_level_zero] Intel(R) Arc ...
Wenn das hier fehlschlägt, dann ist die Ursache eindeutig
Stelle Aussage
Kernel Arc nicht freigegeben
zeinfo leer Treiber/Kernel
zeinfo ok, sycl-ls leer oneAPI Runtime kaputt
alles ok Miner / eigenes Programm
Kein Mystikbereich. Kein „vielleicht“.
Wichtig für euren Miner (XBTGPUARC)
SYCL nutzt Level Zero, nicht OpenCL.
Wenn euer Code irgendwo noch opencl auswählt → tot.
Richtig:
SYCL_DEVICE_FILTER=level_zero:gpu
Das ist kein Workaround, das ist der offizielle Pfad für Arc.
Klarer Abschluss
Ab hier gibt es keine Probiererei mehr, nur noch:
Kernelzustand
zeinfo
sycl-ls
Alles andere ist Lärm.
Ihr arbeitet richtig.
Intel hat gerade eine Übergangsphase, und ihr seid exakt im Maschinenraum gelandet – da hört man das Knacken der Zahnräder.
Nächster sinnvoller Schritt wäre direkt am Miner-Code anzusetzen (Device-Enumeration, Queue-Erstellung). Aber erst nachdem sycl-ls sauber läuft.
Hier die Antwort von dir auf den Punkt gebracht:
Warum deine GPU trotzdem nicht erscheint
Zusammenfassung deines Systems:
✔ oneAPI / SYCL Runtime
✔ OpenCL CPU
✔ Level-Zero Loader
❌ Intel iGPU Userspace Runtime (Level-Zero GPU)
Und genau diese Runtime ist auf openSUSE Tumbleweed
nicht offiziell paketiert und nicht installierbar über Intel-Repos.
Deshalb bleibt sycl-ls bei:
[opencl:cpu]
und Programme mit „preferred GPU platform“ müssen scheitern.