Probleme mit Nvidia unter Linux

[lurks74]

Hi hat jemand von euch Erfahrungen mit AMD und Nvidia unter Linux.

Ich habe ne Nvidia 2070 Super und immer wenn ich mein Rechner aus dem Standby kommt hat X oder auch Wayland Probleme mit der Darstellung des Desktops. In den Logs finde ich nichts.

Auf meinem Firmenlaptop (Intel) habe ich sowas nicht ich bilde mir ein das die Nvidia GPU das Problem ist.

Bin drauf und dran mir ne gebrauchte 6800XT zu besorgen

Hat jemand ähnliche Erfahrungen mit seiner Nvidia GPU unter Linux

[raffa]

Was für einen Kernel benutzt du?

Zu nvidia kann ich nix sagen, aber
mit Kernel 6.1 gibt es wohl Probleme mit dem resume.
Mein Rechner zb friert ein (Mauszeiger is sichtbar, sonst schwarz, tty wechseln geht nicht)
Andere berichten ähnliches.

Aber bei dir gibts Bildfehler, keine freezes?

[lurks74]

Diesen hier verwende ich
Linux $HOSTNAME 6.1.4-arch1-1

Ne freezes habe ich nie nur Bildfehler z.B. Fenster nur mit Rand und keinem Inhalt.
Diese Bildfehler nerven mich unendlich sodass ich bald bereit bin 500-600€ für ne AMD 6800-6900xt auszugeben.

Vorher hatte ich ne Nvidia 970 ich meine da war es besser aber damals habe ich auch noch Windows genutzt.
Und Windows ist keine Option mehr die Spiele die ich brauche gehen auch auf Linux, zur NOT habe ich ne PS5/XSX aber geht nichts über PC Gaming

[raffa]

gleicher Kernel bei mir. auch arch

genauen Zeitpunkt kann ich nicht sagen, ein Nachteil des Rolling-Release Modells
Irgendwann mit Kernel 6.x hatte ich auf einmal wakeup freezes.

amdgpu (radeon 7850)

Der Laptop mit 6.1.1 und intel hat das Problem nicht, ich mach mal eben ein pacman -Syu

edit: der lappi (yoga 260, i5) wacht auch mit kernel 6.1.4 normal auf

gesendet von tapatalk ;)

[Marscel]

NVidia und Linux ist eine schlechte Kombi: Ich las irgendwo von einem Nouveau-Maintainer, wie viel Aufwand und Reverse Engineering das war, die ganzen closed Firmwares auf einer Karte richtig zu booten, und was dann immer alles noch krüppelig ist.

Die NV-Treiber sind für einige GPUs mittlerweile teilweise open, aber Ubuntu warnt immer noch vor auffälligen Glitches bei v525.

Achja, und ich hatte letztens auch zwei ältere Geforces auf einem Live-Stick im Betrieb, und das war suboptimal, wenn da schon Auflösung und Refresh-Rates Probleme machen.

Linux und brauchbare Ausgabe ohne irgendwelche Umwege aktuell immer noch: AMD oder Intel.

[raffa]

Da bin ich bei Marscel.

Wenn man dann noch Wayland benutzen will, isses ganz vorbei.
Die Gaming Performance ist aber ganz brauchbar

https://www.phoronix.com/review/radeon2022-windows-linux
https://www.phoronix.com/review/nvidia2022-windows11-linux


Der amdgpu Treiber ist wirklich gut inzwischen, aber auch da ist man manchmal nicht vor überraschungen gefeilt und ein offizielles Control Panel fehlt, soweit ich weiss.

Woher die aktuellen wakeup freezes kommen, weiss ich aber bisher nicht und hab grad auch keine rechte lust zu suchen.

- edit: mit dem lts-kernel (Linux 5.15.86-1-lts) geht der resume

"Achja, und ich hatte letztens auch zwei ältere Geforces auf einem Live-Stick im Betrieb, und das war suboptimal, wenn da schon Auflösung und Refresh-Rates Probleme machen."

Gestern beim Neffen ein Ubuntu 22.04 LTS installiert, gpu war eine passive Club3D Radeon HD 4650, völlig problemlos. Das müsste dann der "radeon" treiber sein.

[Shink]

Auch von mir die Empfehlung: NVidia unter Linux ist nett für eine gewisse Generation von Spielen und auch unter Raytracing viel besser - einfach, weil der Treiber sich viel mit dem Windows-Treiber teilt.
Für ein stabiles System ist das aber nichts. Man braucht nicht darauf warten, dass irgendein Bug behoben wird; was NVidia gerade macht, fixt oder interessiert weiß man nicht. Nach dem ersten VulkanWayland-fähigen NVidia-Treiber hab ich meine Karte verkauft. Das wird vermutlich nie was.
Bei AMD kannst du eine 10 Jahre alte Karte einbauen und ziemlich sicher sein, dass die Treiber besser funktionieren als vor 10 Jahren.

€: Hoppla, hab mich vertan. Vulkan funktioniert schon...

[lurks74]

Ich bin drauf und dran mir ne RDNA2 GK zu kaufen und ich hoffe das die Probleme sich dann legen. Die 2070 bekommt dann die Tochter ;) .

[lurks74]

Habe mir ne 6900XT gekauft und was soll ich sagen die Probleme haben sich in Luft aufgelöst.

Keine Probleme mit Wayland / X auch nach dem StandBy nicht, ich bin begeistert.

[Berniyh]

Willkommen in der Welt der guten Open Source Treiber. :)

[raffa]

Fein!

Mein freeze on resume problem besteht leider immer noch
Hab ein wenig gestestet, ab 5.19 tritt das auf und im Journal sieht man lediglich, das S3 erreicht wurde, dann endet das log...

edit:
wenn ich radeon.si statt amdgpu.si benutze ändert sich wenig nennenswertes
ich bin also nicht schlauer geworden

[Marscel]

Mein freeze on resume problem besteht leider immer noch
Hab ein wenig gestestet, ab 5.19 tritt das auf und im Journal sieht man lediglich, das S3 erreicht wurde, dann endet das log...

Kennst du dich mit Kernel-Bisection (https://wiki.ubuntu.com/Kernel/KernelBisection) aus? Falls ja, ich hab ein ähnliches Problem mit Sx mal einen Tag lang zwischen guter und schlechter Version kompiliert (kann man nebenbei machen lassen) und es soweit auf eine Änderunge einengen können, dass ichs im Bugtracker posten und immerhin einen Workaround von den Maintainern kriegen konnte.

[raffa]

Excellent Idea!

Keine Ahnung von Kernel-Bisection, noch nicht.
Da das Problem selbst mit dem 6.2rc4 noch besteht, werd ich mir die Mühe mal machen.

[Langenscheiss]

Hab den 5.15 Kernel mit ner RTX A4000 mobile und dem treiber 515.43 in einem workstation laptop. Freezes gibt es nicht, aber es kommt manchmal vor, dass er nach nem resume nicht mehr in den high power mode switchen kann, sprich wenn ich meinen CUDA Code laufen lasse, bekomme ich dann miese performance. Workaround dafür ist schlicht, nochmal in standby zu gehen, und dann wieder zu resumen.

[The_Invisible]

Auch von mir die Empfehlung: NVidia unter Linux ist nett für eine gewisse Generation von Spielen und auch unter Raytracing viel besser - einfach, weil der Treiber sich viel mit dem Windows-Treiber teilt.
Für ein stabiles System ist das aber nichts. Man braucht nicht darauf warten, dass irgendein Bug behoben wird; was NVidia gerade macht, fixt oder interessiert weiß man nicht. Nach dem ersten VulkanWayland-fähigen NVidia-Treiber hab ich meine Karte verkauft. Das wird vermutlich nie was.
Bei AMD kannst du eine 10 Jahre alte Karte einbauen und ziemlich sicher sein, dass die Treiber besser funktionieren als vor 10 Jahren.

€: Hoppla, hab mich vertan. Vulkan funktioniert schon...

Naja stabil ist es schon (unter X), arbeite hier selbst schon seit über 20 Jahren nativ mit Nvidia und Linux produktiv. Probleme gibts eher wennst mehr im BleedingEdge unterwegs bist, vor allem Wayland & Co. Wollte diese Gen eigentlich auch mal eine Radeon versuchen weils unter Linux besser gehen soll aber die RT Performance ist leider ja noch immer fün Popo und auch kein DLSS.

[Berniyh]

aber die RT Performance ist leider ja noch immer fün Popo und auch kein DLSS.
Also für Raytracing würde ich mir sowas wie Nvidia nicht antun, zumindest unter Linux. ;)
Zudem denke ich, dass man unter Linux typischerweise andere Sorgen hat als Raytracing.

Excellent Idea!

Keine Ahnung von Kernel-Bisection, noch nicht.
Da das Problem selbst mit dem 6.2rc4 noch besteht, werd ich mir die Mühe mal machen.
Es ist generell eine gute Idee sich mit git anzufreunden.
Es ist schließlich das Versionsverwaltungssystem, das, ursprünglich für den Linux Kernel von Linus Torvalds entwickelt, inzwischen gefühlt 99.99% der Entwickler nutzen.
Der Rest sind hauptsächlich einige vereinzelte Projekte die bei cvs, subversion oder bizarre hängen geblieben sind. Ganz selten sieht man auch mal noch mercurial, was zu Beginn von git noch als Alternative recht verbreitet war, gibt es aber auch nicht mehr so häufig.
(Ok, bzr war nie wirklich verbreitet, dennoch sieht man hin und wieder mal ein Projekt das das nutzt.)

git bisect ist nur eine der vielen sehr nützlichen Funktionen die git bietet. Das gibt es noch viel mehr. ;)

[aufkrawall]

Zudem denke ich, dass man unter Linux typischerweise andere Sorgen hat als Raytracing.

Ja und nein, es läuft schon einiges mit VKD3D-Proton. Sei es Metro Exodus Enhanced oder Dying Light 2.
Aber ja. Für die Psycho-Hygiene würd ich auch erstmal mit Linux-Gaming abschließen, bis eines Tages der Nvidia-Treiber unter Linux weniger Krampf ist oder AMD sich mit ihrem GPU-Paket insgesamt mal wie ein konkurrenzfähiger Anwärter auf Platz 1 darstellt. Letzteres ist wohl noch eine Spur hypothetischer...

[Berniyh]

Ich wollte auch nicht sagen, dass es nicht geht, aber wenn ich die Wahl habe zwischen Raytracing in einigen wenigen Spielen und einem (größtenteils) sorglosen Treiber, dann weiß ich wo bei mir persönlich die Wahl liegt. ;)

Ich hatte den Murks mit den geschlossenen Treibern früher sowohl mit ATI (ja, ATI, nicht AMD …) als auch mit Nvidia und bin echt froh, dass ich das hinter mir habe.

[aufkrawall]

Das Problem ist weniger, dass der von Nvidia proprietär anstatt open ist, sondern, dass ständig Dinge regressen und extrem lahmarschig gefixt werden. Das Regression-Management von Kernel und Mesa ist einfach besser (wobei die natürlich auch gerne noch weniger regressen dürfen, aber ist unterm Strich vermutlich schon nicht schlecht).
Nvidia arbeitet da gefühlt teilweise immer noch wie eine CAD-Butze aus den frühen 0er-Jahren...

[Berniyh]

Das Problem ist weniger, dass der von Nvidia proprietär anstatt open ist, sondern, dass ständig Dinge regressen und extrem lahmarschig gefixt werden. Das Regression-Management von Kernel und Mesa ist einfach besser (wobei die natürlich auch gerne noch weniger regressen dürfen, aber ist unterm Strich vermutlich schon nicht schlecht).
Nvidia arbeitet da gefühlt teilweise immer noch wie eine CAD-Butze aus den frühen 0er-Jahren...
Ähm, das hängt doch alles zusammen. Regressionen hast du eben gerade, weil der Treiber von Nvidia proprietär ist.
Bei AMD gibt es die auch, aber wird halt im Normalfall in den RCs ausgebügelt.
(Was aber nicht heißen soll, dass das nicht trotzdem manchmal durchgeht, ist aber seltener.)

[aufkrawall]

Ähm, das hängt doch alles zusammen.
Nicht wirklich. Unter Windows haut Nvidia mal einen Beta-Branch raus (auch, wenn sie es nicht Beta nennen...), der dann häufig 1-2 Monate später ziemlich ausgereift ist. Unter Linux zieht sich das Elend mitunter über Jahre. Einfach, weil es ihnen egal ist.

[Benutzername]

Nicht wirklich. Unter Windows haut Nvidia mal einen Beta-Branch raus (auch, wenn sie es nicht Beta nennen...), der dann häufig 1-2 Monate später ziemlich ausgereift ist. Unter Linux zieht sich das Elend mitunter über Jahre. Einfach, weil es ihnen egal ist.


Ist ja auch kein Wunder, die meisten Benutzer benutzen kein Linux zum Destop Gaming. Gaming unter Linux ist halt ganz nett aber nicht so wichtig im Vergleich zum Windows Treiber.

[Berniyh]

Nicht wirklich. Unter Windows haut Nvidia mal einen Beta-Branch raus (auch, wenn sie es nicht Beta nennen...), der dann häufig 1-2 Monate später ziemlich ausgereift ist. Unter Linux zieht sich das Elend mitunter über Jahre. Einfach, weil es ihnen egal ist.
Tja und wenn man ein anderes Entwicklungsmodell hat, dann funktioniert es auch so.
Also eben doch. ;)

Zudem kannst du das nicht so ganz vergleichen, denn unter Windows werden andere Teile des Treibers angepasst, nämlich eher der Teil, der auch unter Linux eh Closed Source ist und nicht in direktem Zusammenhang mit dem Kernel steht.

Aber wie man es auch immer betrachtet, wenn man Linux nutzen will (und das muss natürlich jeder für sich selbst entscheiden), dann ist Nvidia einfach keine wirklich gute Option.

[raffa]

Es ist generell eine gute Idee sich mit git anzufreunden.
Es ist schließlich das Versionsverwaltungssystem, das, ursprünglich für den Linux Kernel von Linus Torvalds entwickelt, inzwischen gefühlt 99.99% der Entwickler nutzen.
...

git bisect ist nur eine der vielen sehr nützlichen Funktionen die git bietet. Das gibt es noch viel mehr. ;)

git kenn ich und wir benutzen das auch für unsere Projekte,
Allerdings war mir "git bisect" neu, hab ich bisher nicht benötigt.

Ich bin noch allzuweit gekommen, das arch buildystem ist mir noch nicht so vertraut,
und so einen alten Kernel bauen scheitert gerne auch mal an einem zu neuen gcc oder oder oder...

Dazu ist mein Rechner eigentlich zu langsam, so ein Athlon x4 845 kompiliert ganz schön hin an einen Kernel mit Modulen, Docs usw.
Mit localmodconfig und ohne docu gehts aber halbwegs,

ich kämpf mich durch :)


Topic:

Für mich ist nvidia deswegen raus aus der Auswahl. Was schade ist. Windows ist als Hauptsystem keine Option mehr für mich, und der Linux Desktop ist mitlerweile gut genug, um auch spielen zu können, musik zu machen, zu rendern usw.
Mit Proton, (d3d)Vulkan, steam (auch wenn valve da noch viel arbeit hat), pipewire, wayland, kde plasma/gnome ist das ein völlig anderes Desktopsystem als noch vor ein paar Jahren.

[Berniyh]

Ich bin noch allzuweit gekommen, das arch buildystem ist mir noch nicht so vertraut,
und so einen alten Kernel bauen scheitert gerne auch mal an einem zu neuen gcc oder oder oder...
Hast Glück, dass ich das vor 2 Wochen auch erst gemacht habe um ein Problem im Soundtreiber zu finden und mit den Problemen vertraut bin. :D
Bei manchen Versionen musst du eine BTF Option deaktivieren.
Dazu
make nconfig
(oder xconfig) aufrufen und dann
Kernel hacking → Compile-time checks and compiler options → Generate BTF typeinfo
deaktivieren. Damit entgehst du einem Kompilierfehler. Das Deaktivieren der Option sollte für dich irrelevant sein, d.h. dein Problem sollte sich genauso reproduzieren lassen.
Als zweites brauchen noch ältere Kernel (ich glaube älter als 5.18, bin mir aber nicht ganz sicher) auch noch einen Patch. Den hänge ich an. Die Dateiendung in '.patch' ändern und dann mit git am oder patch -p1 -i einpflegen.
Dazu meine Rechner eigentlich zu langsam, so ein Athlon x4 845 kompiliert ganz schön hin an einen Kernel mit Modulen, Docs usw.
Mit localmodconfig und ohne docu gehts aber halbwegs,
Sofern du das Problem reproduzieren kannst ist das natürlich ok, aber prinzipiell würde ich eher die default Config nutzen mit der der Kernel gebaut wurde den du auch sonst nutzt. Nicht, dass sich das sonst anders verhält.
Wenn du noch einen potenteren Linux PC hast, dann kannst du den Kernel auch auf dem kompilieren. Hat man mit ssh auch schnell hin und her geschoben.
Dazu am besten make install_modules beim Kernel mit der Umgebungsvariable INSTALL_MOD_PATH ausführen der auf irgendein Verzeichnis zeigt, welches du dann mit 7z o.ä. packen kannst (Vorher natürlich auch noch das Kernel Image dorthin kopieren). Für make install gibt es auch eine Variable INSTALL_PATH, allerdings wird make install glaube ich auf Arch von irgendeinem Skript abgefangen das auch gleich noch dracut oder so ausführen will, was auf Arch aber irrelevant ist. (Ich glaube das Skript stammt eigentlich von systemd, bin mir gerade nicht mehr ganz sicher)
Ich habe den Kernel immer manuell kopiert. War am Ende einfacher.

Mit Proton, (d3d)Vulkan, steam (auch wenn valve da noch viel arbeit hat), pipewire, wayland, kde plasma/gnome ist das ein völlig anderes Desktopsystem als noch vor ein paar Jahren.
Da muss ich dir zustimmen. In den letzten 10 Jahren ist da echt viel passiert, ich hätte vor 5 Jahren auch nicht gedacht, dass ich Windows auf dem Spiele-PC wirklich mal beerdigen könnte. Jetzt ist es aber wirklich in Aussicht, eigentlich blockiert nur noch ein einziges Spiel, welches für mich relevant ist, aber nur suboptimal läuft (Assetto Corsa).
Und auch am Desktop hat sich sehr viel gebessert, die Interoperabilität zwischen den Desktopumgebungen/Toolkits ist deutlich besser und wird auch weiter besser werden, dazu wurde mit systemd vieles standardisiert und auch die Qualität ist insbesondere bei KDE (nur das kann ich persönlich beurteilen, da ich andere DEs nicht nutze) in den letzten Jahren wieder gestiegen, nachdem es zwischendurch echt mäßig war. KDE4 war quasi Mittelalter. :freak:

[aufkrawall]

Zudem kannst du das nicht so ganz vergleichen, denn unter Windows werden andere Teile des Treibers angepasst, nämlich eher der Teil, der auch unter Linux eh Closed Source ist und nicht in direktem Zusammenhang mit dem Kernel steht.

Das kannst du, oder sonst irgendjemand, doch gar nicht wissen.
Aber gut, es gibt Plattform-Spezifika, und da ist mit der real miesen Unterstützung durch Nvidia von Xorg und Wayland definitiv ein großer Teil der Probleme zu finden.

[raffa]

Hast Glück, dass ich das vor 2 Wochen auch erst gemacht habe um ein Problem im Soundtreiber zu finden und mit den Problemen vertraut bin. :D
....

Da muss ich dir zustimmen. In den letzten 10 Jahren ist da echt viel passiert, ich hätte vor 5 Jahren auch nicht gedacht, dass ich Windows auf dem Spiele-PC wirklich mal beerdigen könnte. Jetzt ist es aber wirklich in Aussicht, eigentlich blockiert nur noch ein einziges Spiel, welches für mich relevant ist, aber nur suboptimal läuft (Assetto Corsa).
Und auch am Desktop hat sich sehr viel gebessert, die Interoperabilität zwischen den Desktopumgebungen/Toolkits ist deutlich besser und wird auch weiter besser werden, dazu wurde mit systemd vieles standardisiert und auch die Qualität ist insbesondere bei KDE (nur das kann ich persönlich beurteilen, da ich andere DEs nicht nutze) in den letzten Jahren wieder gestiegen, nachdem es zwischendurch echt mäßig war. KDE4 war quasi Mittelalter. :freak:

Thx for the infos. Ich hab das PKGBUILD derzeit soweit im Griff und grad das erste god/bad Pärchen gebaut. (Kernel 5.18. als Startversion gibts über downgrade, den hatte ich schon getestet)
Wenn ich ein Ergebnis hab, werd ich das noch mit der default Config überprüfen.
Ich hätt noch nen vserver den ich bauen lassen könnt, aber ne, so schnell ist der auch nicht, und jetzt kann ich das nebenher machen.
Wenigstens lässt sich der bug leicht reproduzieren: booten, schlafenlegen, aufwecken -> [no]freeze

--

hehe,
bei mir ists iRacing was nicht läuft und ich irgendwann wieder spielen können will.

[Berniyh]

Das kannst du, oder sonst irgendjemand, doch gar nicht wissen.
Windows bietet, im Gegensatz zu Linux, stabile APIs für Treiber, darauf wollte ich hinaus.
Thx for the infos. Ich hab das PKGBUILD derzeit soweit im Griff und grad das erste god/bad Pärchen gebaut. (Kernel 5.18. als Startversion gibts über downgrade, den hatte ich schon getestet)
Du kannst über das kernel-lts repository auch noch die lts Kernel (e.g. 5.10) recht schnell testen.
Würde es übrigens eher nicht über ein pkgbuild machen, aus dem simplen Grund, dass man sich Kompilierzeit spart, wenn man es einfach direkt im git Verzeichnis macht. (Make erkennt ja, was neu gebaut werden muss)
Die Dateien, die man auf dem System verteilt sind recht überschaubar, eigentlich nur in /boot und /lib/modules, das ist auch schnell wieder manuell entfernt.
Etwas nervig ist, dass man auch das initrd manuell bauen muss, aber das geht auch erträglich schnell.
Ich bin so jedenfalls recht schnell voran gekommen, nach einem halben Tag hatte ich den Fehler. :)
(Und man kann ja nebenher noch etwas anderes machen)
bei mir ists iRacing was nicht läuft und ich irgendwann wieder spielen können will.
Das hab ich nie probiert. Bin nicht so der Fan von Abomodellen. Insbesondere nicht, wenn es halt schon eine super Sim gibt die keins hat. ;)
Zudem bin ich auch nicht so der große Fan von Online Racing, bin zwar letztes Jahr erst in einer Liga mitgefahren, aber die ist jetzt auch passé, insofern bin ich erst mal wieder raus. ^^

[raffa]

Der Linux 5.15.[89-1-]lts läuft prima und ist quasi mein failsafe Kernel.

Ich hab vorher schon die releases per "downgrade" bisectioniert (also bevor du mir das eingebrockt hast :D ), bis ich 5.18.6 good/5.19 bad hatte.
Hätte ich gewusst was das für Stress mit dem PKGBUILD wird, hätte ichs wohl auch manuell gemacht,
aber jetz bleib ich dabei.

[Berniyh]

Der Linux 5.15.[89-1-]lts läuft prima und ist quasi mein failsafe Kernel.

Ich hab vorher schon die releases per "downgrade" bisectioniert (also bevor du mir das eingebrockt hast :D ), bis ich 5.18.6 good/5.19 bad hatte.
Hätte ich gewusst was das für Stress mit dem PKGBUILD wird, hätte ichs wohl auch manuell gemacht,
aber jetz bleib ich dabei.
Der Tipp mit bisect kam nicht von mir. ;)

Und ein bisect startet man am Besten immer direkt von der Urversion einer Majerversion, einfach aus dem Grund, dass sich an dem Punkt die Zweige aufteilen. Die .6 Version könnte ja einige Commits haben, die auch in den 5.19er eingeflossen sind (bzw. ist das sogar ziemlich sicher so).
git bisect macht das zwar automatisch, dass es dann die gemeinsame Basis testet, allerdings ist es da nicht ganz so zielsicher, hatte es schon, dass er mir irgendeine komische Version angeboten hatte.
Von daher am Besten 5.18 als good und 5.19 als bad wählen, dann legt es direkt richtig los.

Man kann es zudem auch noch etwas beschleunigen, indem man bisect beim Start (ok, ist jetzt für dich etwas zu spät) noch ein Verzeichnis mit gibt.
In meinem Fall wusste ich z.B., dass es sich um einen Fehler im USB Soundtreiber handelt, d.h. ich habe bisect so gestartet:
git bisect start -- sound/usb

Dann werden nur commits gecheckt die auch Dateien in dem Verzeichnis modifizieren. Dadurch skipt man so einiges.
Es birgt aber natürlich auch das Risiko, dass man etwas übersieht, weil es evtl. ein Fehler in einem anderen Subsystem ist, welches sich wo anders befindet und sich halt nur an der beobachteten Stelle auswirkt. In deinem Fall hätte man evtl. auf drivers/gpu/drm/amd beschränken können.
Arg viel wird es aber auch nicht ausmachen (evtl. 2-3 Iterationen), denn der Treiber von AMD ist ja mittlerweile einer der größten Bestandteile im Kernel. ^^

[raffa]

Tatsache, das warst du ja gar nicht!

git bisect hat aus dem wunsch bei 5.18.6 anzufangen mich gebeten 5.18 zu testen, der war ok, also hab ich bei 5.18 als good und 5.19 als bad angefangen

Das es am AMD treiber liegt, ist zwar zu vermuten, aber keineswegs sicher.

[The_Invisible]

Also für Raytracing würde ich mir sowas wie Nvidia nicht antun, zumindest unter Linux. ;)
Zudem denke ich, dass man unter Linux typischerweise andere Sorgen hat als Raytracing.



Hab hier DualBoot da primär Windows noch immer mein GameOS ist. Eines Todes muss man sterben, auf RT will ich nicht verzichten, ich hoffe aber auch das Nvidia ihren Arsch hochbekommt und mal bisschen Tempo zulegt im Linux Bereich.

[aufkrawall]

Es sind ja einige Dinge in der Pipeline. Aber ich würde annehmen, dass es noch ein paar Jahre dauern wird, bis das für den Anwender spruchreif ist. Mit den 530er Treibern soll sich wieder etwas tun, aber bislang waren das Trippelschritte über einen langen Zeitraum.

[Berniyh]

Hab hier DualBoot da primär Windows noch immer mein GameOS ist. Eines Todes muss man sterben, auf RT will ich nicht verzichten, ich hoffe aber auch das Nvidia ihren Arsch hochbekommt und mal bisschen Tempo zulegt im Linux Bereich.
Ich hab da ehrlich gesagt nicht so viel Hoffnung. Es gibt immer mal wieder Anzeichen, dass es sich ein bisschen bessert (sie haben ja zwischendurch sogar mal GPU Dokumentationen für ein paar Chips veröffentlicht), aber im Allgemeinen scheint es schon echt so zu sein, dass sie halt immer so das minimale machen was gerade noch geht um nicht komplett ohne Support dazustehen.
Auf eine komplette Kehrtwende braucht man jedenfalls nicht zu hoffen und selbst wenn, bei AMD konnte man ja sehen wie viel Übergangszeit das braucht, bis ein Opensource Treiber auf wirklich festen Füßen steht.
Nur mal so zur Relation: AMD hat ATI 2006 übernommen. So ca. 2008 hat man angefangen zur Open Source Entwicklung aktiv beizutragen, zunächst vor allem mit Dokumentationen zu GPUs, dann immer mehr auch mit eigenen Ressourcen. Seitdem sind immerhin knapp 15 Jahre vergangen und immer noch ist die Featureparität mit dem Windowstreiber nicht ganz erreicht. Zugegeben, an manchen Stellen (z.B. HDR) liegt es nicht an AMD selbst, sondern auch daran, dass es an anderen Stellen der Plattform fehlt, aber auch beim Treiber ist noch nicht alles an Features vorhanden. Zum Glück ist die Anzahl der Fehlstellen inzwischen recht überschaubar, die wichtigsten Dinge sind da. :)
Für AMD war es aber insgesamt wohl recht wichtig eine gemeinsame Entwicklungsbasis für alle Plattformen zu haben. Das und die zwischendurch sehr angespannte Finanzierungssituation bei AMD hatten da sicherlich auch einen großen Einfluss auf die Zeitspanne in der das ganze passiert ist.

Generell muss man einfach mal abwarten, wie sich das mit Linux entwickelt. Wie ja schon bemerkt wurde hat sich bei Linux als Spieleplattform echt sehr viel in den letzten 2-3 Jahren verbessert, seit Valve das aktiv pusht. Auch die Nutzerzahlen laut Steam sind ja noch mal etwas angestiegen und mit Steam Deck gibt es jetzt ja auch eine darauf basierende Konsole, welche ganz gut Absatz zu finden scheint. Dazu kommt, dass Linux durch die zunehmende Standardisierung der Plattform auch für Entwickler wieder etwas attraktiver werden könnte, denn bei vergangenen Projekten war genau die Vielzahl der Distributionen (mit teils eigenen und eigenartigen Lösungen) wohl ein Problem.
Vermutlich müsste man aber in der Steam Nutzerstatistik schon in die Größenordnung von 5% oder höher kommen, damit Nvidia wirklich mal in die Pushen kommt und dem eine höhere Priorität gibt.

[aufkrawall]

Auf eine komplette Kehrtwende braucht man jedenfalls nicht zu hoffen
Die Fakten sind aber anders. Der Fahrplan ist, dass irgendwann der Nvidia-Mesa-Treiber für Vulkan (NVK) mit dem offenen Kernel-Modul von Nvidia direkt funktioniert. Welches irgendwann wiederum upstream im Kernel landen soll. Kannst du im Phoronix-Forum bei Aussagen von RedHat-Entwicklern, die mit Nvidia daran arbeiten, nachlesen.
Ich würde davon ausgehen, dass in fünf Jahren die Situation komplett anders ist als heute. Bis dahin wird es scheibchenweise vorangehen. In zwei Jahren ist ggf. das Gröbste schon über die Bühne gegangen, aber das wäre eine optimistische Einschätzung.

[Berniyh]

Das wäre natürlich schon mal etwas Entspannung, aber eine komplette Kehrtwende wäre das auch nicht.
Der Vulkantreiber wird zwar zukünftig immer wichtiger werden, insbesondere, wenn OpenGL dann über Zink laufen kann und OpenCL obsolet wird (oder auch über rusticl laufen kann), allerdings ist das dann trotzdem nur ein Teil dessen was der Treiber alles macht.
Überleg mal wie groß der amdgpu Kerneltreiber (inkl. DisplayCode) ist im Vergleich zu radv, d.h. dem Vulkantreiber.
Ich hab mir das offene Nvidia Modul schon lange nicht mehr angeschaut, aber ich wäre schon sehr erstaunt, wenn das auch nur annähernd diese Funktionalität wie amdgpu hätte. Bislang war das mehr so eine Art Klebeschicht um den geschlossenen Teil zu laden.
Und wenn es so groß wäre und den Umfang hätte, dann würde es vermutlich sehr lange dauern und viel Aufwand sein das in den Kernel zu bekommen.
AMD kann da ein Lied von singen. Bei DC (bzw. ursprünglich DAL) hat es glaube ich über 2 Jahre und unzählige Iterationen gedauert bis das akzeptiert wurde.
Insbesondere dürfte es schwierig sein Nvidia davon zu überzeugen, ihr Zeug auf bestehende Schnittstellen aufzubauen. (Was auch bei AMD ein Problem war, die mussten auch deshalb einiges umschreiben.)
Wenn man AMD um 2010 herum gefragt hätte, wie lange es dauern würde bis man annähernd Parität mit Windows bei den Features hat, dann hätte da wohl auch keiner mit "+10 Jahre!" geantwortet.:freak:

[aufkrawall]

Ich hab mir das offene Nvidia Modul schon lange nicht mehr angeschaut, aber ich wäre schon sehr erstaunt, wenn das auch nur annähernd diese Funktionalität wie amdgpu hätte. Bislang war das mehr so eine Art Klebeschicht um den geschlossenen Teil zu laden.

Bin mir relativ sicher, dass das ein (halbwegs) "vollwertiger" Kernelmode-Treiber ähnlich zu amdgpu und i915 ist.

[Berniyh]

Bin mir relativ sicher, dass das ein (halbwegs) "vollwertiger" Kernelmode-Treiber ähnlich zu amdgpu und i915 ist.
Ähm … also wenn das so wäre, dann gäbe es keinen Ärger, denn der Teil des Kernelmoduls steht ja unter MIT/GPLv2.
(Muss auch so sein, sonst gäbe es eine Lizenzverletzung. Selbst so gibt es ja Stimmen die behaupten Nvidia würde die Lizenz des Kernels verletzen, weil das Kernelmodul nicht offene Teile nachlädt. Aus dem Grund wird der Treiber auch bei vielen Distributionen nicht ausgeliefert.)

Ich hab mir mal die aktuelle Version (525.85.05) des Treibers runtergeladen.
Der kernel-open Teil enthält .c und .h Dateien im Umfang von 176757 Zeilen Code zu enthalten.

Zum Vergleich: drivers/gpu/drm/amd enthält etwa 4.8 Millionen Codezeilen.
Selbst wenn man sich hier auf die Unterverzeichnisse amdgpu, pm und display beschränkt (und damit die umfangreichen hardwarespezifischen Registerdateien in include weglässt) ist man immer noch bei etwa 800000 Codezeilen.

Also entweder haben die Nvidia Programmierer da sehr viel schlanker programmiert als AMD oder das Ding ist doch nicht ganz so vollständig. ;)
Bin da also noch etwas skeptisch.
Wir werden ja sehen in welche Richtung sich das entwickelt.

[aufkrawall]

AMD läuft (inoffiziell) auch runter bis Southern Islands (7970 von 2012), der Nvidia-Treiber unterstützt nur >=Turing.

[Ganon]

Nvidia hat sehr viel Kram der bei AMD Open Source ist in einen geschlossenen Firmware Blob gepackt der von der Karte selbst in einem separaten SoC verarbeitet wird.

[Marscel]

Hab ich auch vermutet, aber haben die dadurch auch weniger Last auf der Host-CPU? :uponder:

[Ganon]

Da geht's nicht um Berechnungen, sondern um GPU Initialisierung, Output Management und all so ein Kram. Ist genau so ein Kram wie bei WLAN Modulen oder der Videodekodierung bei anderen Grafikkarten. Hat die Firmware ein Bug bzw. tut nicht das was sie soll, bringt es dir nichts, das Interface zur Firmware (der Treiber) Open Source ist.

[Marscel]

Klar gehts da nicht um Berechnungen, aber wohl ja auch um Ressourcenmanagement, Scheduling, Monitoring und Power-Kram, wenn ich die Nouveau-Leute richtig verstehe.

Ich vermute weniger, dass die das machen, um auf Linux IP zu verstecken, das ist uninteressant, sondern weil das irgendwie beneficial ist, vielleicht weil es weniger auf dem Host tun lässt, Latenzen spart.

[Ganon]

Naja, nach der Logik könnten sie dann ja auch einfach die Firmware OpenSource machen. Tun sie aber nicht.

[Marscel]

Ich stelle mir nur die Nvidia-Ingenieure vor, wie sie den Chip designen: Lasst uns mal viel mehr auf die Firmwares der GPU packen weil a.) wir haben dann den Vorteil, dass ... oder b.) dann zeigen wir es den Linux-GPL-Hippies!

b.) schwingt da bei NVidia vielleicht echt ein wenig mit, aber ich kann mir kaum vorstellen, dass das die Prio dabei war. ;)

[Shink]

Nvidia muss G-Sync, DLSS und ihren ganzen patentierten Krempel unterstützen. Vermutlich wollen sie dann auch nicht, dass man unangebracht Over/Underclocked/volted etc.

[aufkrawall]

Tja, nur kann auch amdgpu unter Linux etwa kein HDMI 2.1 VRR. So ist die Welt leider. :(

[Ganon]

b.) schwingt da bei NVidia vielleicht echt ein wenig mit, aber ich kann mir kaum vorstellen, dass das die Prio dabei war. ;)

Naja, sie sind bekannt dafür, Firmwares nicht bereitzustellen, zu signieren/verschlüsseln und was weiß ich und damit effektiv sowohl ihr IP zu wahren als auch die Open Source Entwicklung zu behindern.

Dass sie erst einen nennenswerten Open Source Treiber veröffentlichen, NACHDEM sie fast all ihren Kram hinter einen Closed Source Firmware Blob gepackt haben, ist doch nicht einfach nur ein simpler Zufall. Da zu argumentieren, dass das alles rein einfach nur einen Effektivitäts-Hintergrund hat, ist (sorry) schon sehr naiv.

Das ist ja nicht mal großartig nur gesagt, um Nvidia zu bashen. Auch Intel und AMD GPUs funktionieren ohne geschlossene Firmware Blobs nicht oder nur stark eingeschränkt. Mein bisher einziges Problem mit amdgpu damals war sogar ein Bug in der Firmware. Es ist schlicht nur so, dass Nvidia hier einfach noch mehr Kram in der Firmware hat als der Rest und man hier letztendlich effektiv weniger Vorteile am Open Source Treiber hat als anderswo.

[Marscel]

Dass sie erst einen nennenswerten Open Source Treiber veröffentlichen, NACHDEM sie fast all ihren Kram hinter einen Closed Source Firmware Blob gepackt haben, ist doch nicht einfach nur ein simpler Zufall. Da zu argumentieren, dass das alles rein einfach nur einen Effektivitäts-Hintergrund hat, ist (sorry) schon sehr naiv.

Ein simpler Zufall ist das mitnichten, höchstwahrscheinlich steht da nichts allzu spannendes nun mehr drin.

Aber in erster Linie will man doch AMD ausstechen bzw. kleinhalten, so wie Intel vor vielen Jahre und lange von z. B. besserer Branch Prediction in ihren CPUs profitierte. Das Interesse bei NV an Linux (für Spieler, oder einfach nur Desktop-Nutzung) muss doch angesichts von Treiber-Policy und Ignoranz, mal die geringsten Infos in Bezug auf Modesettings oder ein bisschen Powermanagement herauszurücken, bis zuletzt im Bereich von don't care sein, sah Linus vor 10 Jahren ja auch schon so. Hin zu dem Punkt, an dem ich mich wundere, warum sie da überhaupt einen Treiber maintainen, denn bis zum Steam Deck oder so rechtfertigte Linux anteilig am Markt ja nicht einmal irgendwas, nüchtern gesehen, Windows ist dafür unkritische Platzhirsch. Warum beim GPU-Design sowas bedenken?

[Ganon]

Warum beim GPU-Design sowas bedenken?

Unterschätze mal nicht die "kleinen" Dinge. Hättest du dir 2013, als Docker released wurde, gedacht, dass es dazu führt, dass Microsoft First-Class Linux Support in Windows einbaut? Oder dass sogar Apple damit wirbt, wie leicht man eine Linux-Umgebung in macOS eingerichtet bekommt?

Hättest du 2008 geglaubt, als Google Chrome released wurde, dass das mal die technische Basis für Microsofts Browser wird?

Damals steckte auch das Linux-Desktop-Ökosystem stark im Arsch von Nvidia. Auch das hat sich spätestens mit ersten größeren Wayland-Bewegungen stark gewandelt. Heute kräht kaum einer danach was Nvidia will, es wird schlicht gesagt, dass es nicht mit Nvidia funktioniert und damit hat sich die Sache.

Sicherlich ist Nvidia weiterhin ein großer Platzhirsch, aber die Geschichte hat schon oft genug gezeigt, dass selbst kleine Dinge das ganze Machtgefüge ins Wanken bringen können. Ursache ist meistens, dass man sich auf seinem Thron ausruht und meint, man sei unantastbar.

[aufkrawall]

Heute kräht kaum einer danach was Nvidia will, es wird schlicht gesagt, dass es nicht mit Nvidia funktioniert und damit hat sich die Sache.

Nur unterstützt Nvidia mittlerweile quasi jede "Linux-API", also GL/Vk-Wayland-Extensions, GBM, Kernel Modesetting etc. "Nur" VAAPI fehlt, aber das wird eh durch Vulkan-Video ersetzt (das Nvidia btw. pusht).
Es krankt dann eher an Details, die z.B. Plasma Wayland ziemlich scheiße laufen lassen. Dauert halt noch, aber ein Ende ist absehbar.

[Ganon]

Nur unterstützt Nvidia mittlerweile quasi jede "Linux-API"

Das ist doch gerade mein Punkt. Es ist Nvidia die sich bewegen müssen und mussten und nicht das Ökosystem um sie herum, so wie es davor lief und wie sie es davor haben wollten. Und der nächste Punkt ist eben der Open Source Treiber (mal unabhängig von ultra-fetten Firmware Blobs).

Am Ende haben sie sich dem Linux-Ökosystem gefügt. Und das nicht weil sie so absolut gütig in ihren Absichten sind, sondern weil das Linux-Ökosystem eben einen auf :ufinger: gemacht hat.

[Berniyh]

Naja, sie sind bekannt dafür, Firmwares nicht bereitzustellen, zu signieren/verschlüsseln und was weiß ich und damit effektiv sowohl ihr IP zu wahren als auch die Open Source Entwicklung zu behindern.
Hm? Die Firmware Dateien sind doch in linux-firmware enthalten?
Gut, die neuesten (also for Ada) fehlen noch, aber die werden ja im Treiber mitgeliefert, kann man sich rauskopieren.

[Ganon]

Hm? Die Firmware Dateien sind doch in linux-firmware enthalten?
Gut, die neuesten (also for Ada) fehlen noch, aber die werden ja im Treiber mitgeliefert, kann man sich rauskopieren.

Es geht dabei um Dinge wie:

https://www.phoronix.com/news/NVIDIA-Ampere-Firmware-Blobs

[aufkrawall]

Es geht dabei um Dinge wie:

https://www.phoronix.com/news/NVIDIA-Ampere-Firmware-Blobs
Reclocking-Support für offene Usermode-Treiber ist schon versprochen (hoffentlich nicht mit gekreuzten Fingern oder sonstigen Pferdefüßen, wird man dann sehen...).
Also angeblich auch für Rusticl mit vollem OpenCL 3.0-Support.

[Benutzername]

ich habe hier auch gerade "Spaß" mit dem nvidia Treiber.

pk-client-error-quark: Error while installing package: »installiertes nvidia-dkms-525-Skript des Paketes post-installation«-Unterprozess gab den Fehlerwert 10 zurück (313)

wirft der mir als Fehler mit dem Ubuntu Treibertool aus.

das steht in der make.log

DKMS make.log for nvidia-525.78.01 for kernel 5.19.0-28-generic (x86_64)
Do 2. Feb 23:29:54 CET 2023
make[1]: Verzeichnis „/usr/src/linux-headers-5.19.0-28-generic“ wird betreten
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 " ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \
echo >&2 ; \
/bin/false)
warning: the compiler differs from the one used to build the kernel
The kernel was built by: x86_64-linux-gnu-gcc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
You are using: cc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
make -f ./scripts/Makefile.build obj=/var/lib/dkms/nvidia/525.78.01/build \
single-build= \
need-builtin=1 need-modorder=1

Der Kernel ist also mit GCC12 kompiliert und der nvidia Kram mit gcc11, wenn ich das richtig lese? Wie löse ich das jetzt auf? Den Kernel komplett mit gcc11 übersetzen? Älteren Kernel nehmen? :confused:

Der Bildschirtm bleibt dann dunkel nach dem reboot. Daß der keinen failsafe hat udn auf vorher zurückspringt bei so einem Fehler.

[aufkrawall]

U.a. deshalb installiert man den Nvidia-Treiber via dkms. Gibts bei Arch regulär im Repo.

[Berniyh]

U.a. deshalb installiert man den Nvidia-Treiber via dkms. Gibts bei Arch regulär im Repo.
Das ist doch dkms.

Wahrscheinlich ist der falsche Compiler installiert und ausgewählt.
Ist jedenfalls kein Fehler des Nvidia Treibers.
(Wenngleich mal das Problem mit dem AMD Treiber natürlich nicht hätte.)

[Marscel]

https://askubuntu.com/a/1143434

[Berniyh]

Da würde ich lieber den richtigen Compiler installieren und auswählen. ;)

(Die können typischerweise parallel installiert sein.)

[aufkrawall]

Das ist doch dkms.

Ups. Also klassischer User-Fail + Maintainer-Fail. Das wäre nicht passiert, würde das DKMS-Nvidia-Paket der Distribution die aktuelle GCC-Version voraussetzen. Oder, es wurde es irgendeinem Grund GCC nicht aktualisiert.

[Marscel]

Da würde ich lieber den richtigen Compiler installieren und auswählen. ;)

(Die können typischerweise parallel installiert sein.)

Wie pingelig ist der Check denn? Laut Ubuntu Packages ist GCC12 aktuell bei v12.2.0, der Kernel bei v12.1.0. Und der ältere Bugreport im Link findet v7.3 vs. v7.4 auch schon nicht Ok, d. h. ohne noch mehr Aufwand wird das auf Anhieb so vielleicht auch nichts.

[Berniyh]

Wie pingelig ist der Check denn? Laut Ubuntu Packages ist GCC12 aktuell bei v12.2.0, der Kernel bei v12.1.0. Und der ältere Bugreport im Link findet v7.3 vs. v7.4 auch schon nicht Ok, d. h. ohne noch mehr Aufwand wird das auf Anhieb so vielleicht auch nichts.
Schaut euch doch einfach mal genau an, was da steht.
Es ist gcc 11.3.0 installiert. ;)

[Marscel]

Schaut euch doch einfach mal genau an, was da steht.
Es ist gcc 11.3.0 installiert. ;)

Das ist mir klar. Aber wenn du auf Ubuntu Packages (https://packages.ubuntu.com/kinetic/gcc-12) gehst, ist das Upgrade auf GCC 12 Minor 2 für Ubuntu 22.10, und sein Kernel ist GCC 12 Minor 1.

Und da der Bugreporter auch nur einen Minor-Diff hatte, wird sich der Nvidia Treiber vielleicht wieder quer stellen. Ob der Workaround zw. 11 und 12 ne schlechtere Idee als zw. 12.1 und 12.2 ist, kA, vermutlich nicht.

[raffa]

Kleiner Nachtrag von mir:

Meine Resume Freezes hatten nix mit der GPU zu tun.

Der Front USB 3.0 Header ist der Schuldige, der wacht nicht auf seit einem patch für Kernel 5.19. Wenn da was dranhängt, dann gibts nen freeze, wenn nicht, sind nur die Ports tot.