Nvidia oder AMD als Update

[prian]

Seit 2005 auf CB registriert und noch nie eine AMD Graka? Das nenne ich Markentreue

Yep, meine erste Nvidia war eien Riva 128 und dagegen stand damals nur Voodoo 1 2 3 ....
ATI war damals noch in keinster Weise spruchreif und mich haben NVidia-Karten bisher noch nie enttäuscht.

@Maxysch
Ich habe hier auch nur MEINE Meinung zu NVidia abgegeben, das sollte doch 50% der Fragestellung des TE erschlagen haben.

 

[mibbio]

@foofoobar Ich habe irgendwie den Eindruck, du verstehst den Begriff "Upstream" nicht so richtig.

 

[Maxysch]

das sollte doch 50% der Fragestellung des TE erschlagen haben.

Tut es auch und damit habe ich es nicht verneint, ich bin nur immer ein Gegner der Leute die Fans sind von einem Gewinnorientierten Unternehmen

 

[t0oastaa]

Ich habe bei mir festgestellt, dass FreeSync unter Linux mit AMD um einiges einfacher funktioniert als bei NVIDIA. Falls das relevant ist.

 

[andy_m4]

Ach so, upstream in den offiziellen Kernel-Source-Repos.

Achso. Du meinst, warum der nvidia-Kernel-Anteil nicht offizieller Bestandteil des Linux-Kernels ist.
Dann sag das auch so.
Und verwende keine Fremdwörter, deren Bedeutung Du nicht kennst und nur mal irgendwo aufgeschnappt hast.

 

[foofoobar]

@foofoobar Ich habe irgendwie den Eindruck, du verstehst den Begriff "Upstream" nicht so richtig.

Im Kontext des Linux-Kernels macht der Begriff "upstream" nur einigermaßen Sinn wenn sich das auf die offiziellen Linux-Kernel-Source-Repos bezieht.

Was Fritze Müller irgendwo ins Internet stellt ist in diesem Kontext wenig relevant.

Ergänzung (22. Januar 2025)

Und verwende keine Fremdwörter, deren Bedeutung Du nicht kennst und nur mal irgendwo aufgeschnappt hast.

Beachte den den Kontext. Und klicke ruhig mal meine geposteten Links.

 

[mibbio]

Im Kontext des Linux-Kernels macht der Begriff "upstream" nur einigermaßen Sinn wenn sich das auf die offiziellen Linux-Kernel-Source-Repos bezieht.

Nein, Upstream ist kein Begriff speziell für den Linux-Kernel, sondern beschreibt allgemein nur die Herkunft bzw. die Originalquelle eines Programms bzw. dessen Quellcode. In letzter Instanz ist das entsprechend dessen Hersteller/Entwickler.

Im Falle des Nvidia-Treibers ist Upstream nicht der Kernel, sondern der Quellcode von Nvidia selber. Genauso gibt es bei Chrome, Firefox oder KDE Plasma einen entsprechende Upstream, nämlich Google, Mozilla bzw. KDE.

Und dass der Treiber von Nvidia bzw. dessen Open Source Kernel Module nicht im Quellcode des Kernel direkt mit drin steckt, hat einen ganz simplen Grund. Der Quellcode erfüllt nicht die Voraussetzungen für eine Aufnahme in den Kernel.

 

[andy_m4]

Beachte den den Kontext.

Äußere Dich einfach klar. Dann gibts auch keine Probleme. Und da ich auch nicht der einzige bin, der Dich nicht verstanden hat, darfst Du ruhig mal darüber nachdenken, ob nicht das Verständnisproblem doch vielleicht bei Dir liegen könnte.
Ist ja auch nicht das erste Mal das Du Dich verkürzt (und damit unverständlich) äußerst.

Der Quellcode erfüllt nicht die Voraussetzungen für eine Aufnahme in den Kernel.

Um das mal ergänzend näher auszuführen:
Der Grund ist, das der Treiber zwei geteilt ist und man ein in-Kernel-Bestandteil hat und ein out-of-Kernel-Bestandteil der im Userspace läuft. Die beiden Bestandteile greifen sehr stark ineinander. Die Kernel-Entwickler wollen die Möglichkeit haben API/ABI jederzeit zu ändern (was dann den Treiber kaputt machen würde). Die nvidia-Leute wollen das natürlich selbst in der Hand haben.
Und das nvidia davon abrückt ist erst mal nicht absehbar.

Allerdings hat man natürlich Dank Open-Source die Möglichkeit einen entsprechenden Treiber zu "basteln", der dann eher mit der Linux-Kernel-Philosophie vereinbar ist (vergleichbar mit Nouveau).

 

[foofoobar]

Nein, Upstream ist kein Begriff speziell für den Linux-Kernel, sondern beschreibt allgemein nur die Herkunft bzw. die Originalquelle eines Programms bzw. dessen Quellcode. In letzter Instanz ist das entsprechend dessen Hersteller/Entwickler.

Im Kontext des Linux-Kernel benutzt kein Schwein diesen Begriff so wie in diesen Zitat.

Und warum ist der Nvidia-Kram nicht upstream? Ist die Qualität zu schlecht?

 

[mibbio]

Und warum ist der Nvidia-Kram nicht upstream? Ist die Qualität zu schlecht?

Löse dich doch einfach mal, nur im Kontext des Kernels von Upstream zu reden. Ob irgendwas Upstream ist, hat rein gar nichts damit zu tun, ob etwas im Kernel ist oder nicht.

Auch die Treiber von Intel und dessen Quellcodes sind im Kernel enthalten, trotzdem ist Upstream weiterhin Intel und nicht der Kernel. Denn Intel entwickelt die Treiber und gibt die dann, quasi Downstream, an die Kernelentwickler weiter.

 

[andy_m4]

Löse dich doch einfach mal,

Möglicherweise ist das ja so ein "Crush". Ein neues Wort aufgeschnappt und weil er das so toll findet, wird es bei jeder Gelegenheit benutzt. Egal obs passt oder nicht. :-)

 

[BOBderBAGGER]

Läuft Nvidia mit allen Features auf Linux ohne Probleme

Es ist sofern man den Nvidia Treiber nutzt besser geworden allerdings hakt es hier und da noch mit z.B Wayland, Freesync mit Mutimonitor ist wohl auch immer noch eine Baustelle.

 

[prian]

Tut es auch und damit habe ich es nicht verneint,

Soweit, so gut.

ich bin nur immer ein Gegner der Leute die Fans sind von einem Gewinnorientierten Unternehmen

Ich bin kein Fan von NVidia, mich überzeugen die Produkte einfach mehr.
Ich bin jedenfalls KEIN Fan von AMD wenn es um Grafikkarten geht.

Aber das wird dem TE auch nicht weiter helfen. 😱

 

[mibbio]

Und das nvidia davon abrückt ist erst mal nicht absehbar.

War ja schon fast eine Überraschung, dass wir jetzt überhaupt schon mal den aktuellen Zwischenschritt mit der Zweiteilung haben. Mehr wird da in der Richtung seitens Nvidia wohl nur passieren, wenn es entsprechenden Druck aus der Indutrie gibt, also von Unternehmen die Nvidia-Karten in großem Maßstab unter Linux verwenden und einen vollständig quelloffenen Treiber direkt im Kernel wollen.

Ob irgendwelche Privatnutzer mit der aktuellen Situation zufrieden sind, dürfte Nvidia vergleichsweise wenig interessieren.

 

[andy_m4]

wenn es entsprechenden Druck aus der Indutrie gibt, also von Unternehmen die Nvidia-Karten in großem Maßstab unter Linux verwenden und einen vollständig quelloffenen Treiber direkt im Kernel wollen.

Ja. Das war ja schon der der Antreiber die GPU-Treiber überhaupt zu öffnen. Weil wenn irgendwo large-scale-gpu-computing gemacht wird, dann ist das ja vor allem unter Linux.

Ob da auf absehbare Zeit was Brauchbares kommt, was dann im offiziellen Linux-Kernel landet, bleibt abzuwarten.
Ich meine, wenn die Industrie das wirklich will, könnte sie das ja notfalls auch selbst stemmen. Da ist ja offenbar das Geld nicht knapp. Da kommt aber auch nix (zumindest ist nichts zu sehen). So wichtig scheint denen das dann also nicht zu sein. Möglicherweise wollen die das aber auch deshalb nicht, weil die ähm ... Upstream-Entwicklung von nvidia kommt und ein weiterer freier Treiber dem ständig hinterher programmieren muss, um z.B: auch neue Grafikkarten die raus kommen, zu supporten.

 

[foofoobar]

Äußere Dich einfach klar. Dann gibts auch keine Probleme. Und da ich auch nicht der einzige bin, der Dich nicht verstanden hat, darfst Du ruhig mal darüber nachdenken, ob nicht das Verständnisproblem doch vielleicht bei Dir liegen könnte.
Ist ja auch nicht das erste Mal das Du Dich verkürzt (und damit unverständlich) äußerst.


Um das mal ergänzend näher auszuführen:
Der Grund ist, das der Treiber zwei geteilt ist und man ein in-Kernel-Bestandteil hat und ein out-of-Kernel-Bestandteil der im Userspace läuft. Die beiden Bestandteile greifen sehr stark ineinander. Die Kernel-Entwickler wollen die Möglichkeit haben API/ABI jederzeit zu ändern (was dann den Treiber kaputt machen würde). Die nvidia-Leute wollen das natürlich selbst in der Hand haben.
Und das nvidia davon abrückt ist erst mal nicht absehbar.

NV kann genauso wie der Rest der Upstream commiten.
Warum kann NV etwas nicht was der Rest der Welt kann?

BTW: Interne Kernelschnittstellen können sich jederzeit ändern (deswegen sind non-upstream Treiber auch nur ein second class citizen) Schnittstellen Richtung Userspace sind stabil.

Ergänzung (22. Januar 2025)

War ja schon fast eine Überraschung, dass wir jetzt überhaupt schon mal den aktuellen Zwischenschritt mit der Zweiteilung haben. Mehr wird da in der Richtung seitens Nvidia wohl nur passieren, wenn es entsprechenden Druck aus der Indutrie gibt, also von Unternehmen die Nvidia-Karten in großem Maßstab unter Linux verwenden und einen vollständig quelloffenen Treiber direkt im Kernel wollen.

Die Zweiteilungen in User- und Kernel-space haben die anderen GPU-Treiber genauso.

Möglicherweise traut sich NV einfach nicht seine Bugs zu zeigen:

Further tests would have been interesting. I wanted to test CPU to GPU bandwidth using the GPU’s copy engine. DMA engines can queue up memory accesses independently of CPU (or GPU) cores, and are generally more latency tolerant. Nemes does have a test that uses vkCmdCopyBuffer to test exactly that. Unfortunately, that test hung and never completed. Checking dmesg showed the kernel complaining about PCIe errors and graphics exceptions. I tried looking up some of those messages in Linux source code, but couldn’t find anything. They probably come from a closed source Nvidia kernel module. Overall, I had a frustrating experience exercising NVLink C2C. At least the Vulkan test didn’t hang the system, unlike running a plain memory latency test targeting the HBM3 memory pool. I also couldn’t use any OpenCL tests. clinfo could detect the GPU, but clpeak or any other application was unable to create an OpenCL context. I didn’t have the same frustrating experience with H100 PCIe cloud instances, where the GPU pretty much behaved as expected with Vulkan or OpenCL code. It’s a good reminder that designing and validating a custom platform like GH200 can be an incredibly difficult task.

https://chipsandcheese.com/p/grace-hopper-nvidias-halfway-apu

Ob irgendwelche Privatnutzer mit der aktuellen Situation zufrieden sind, dürfte Nvidia vergleichsweise wenig interessieren.

Also würdest du keine Kaufempfehlung für Produkte von NV abgeben wenn dem Laden seine Kunden am Arsch vorbei gehen?

 

[Kaito Kariheddo]

Also von den Spiele-Tests gleich zu Release kann ich sagen: Mit AMD läufts in der Regel direkt ab erscheinen, Nvidia hingegen bringt da oft weniger Leistung als die Game Ready Treiber unter Windows. Manchmal gibts sogar immer noch Kompatibilitätsprobleme bei Spiele-Neuerscheinungen. Also sollte dir das wichtig sein, wäre AMD die bessere Wahl. Wenn du hingegen nur bestimmte Spiele hast, kannst du vorab schauen wie die Kompatiblitäts ist: ProtonDB hat einen Filter nach Grafikkarten. Aber in der Regel hast du mit AMD am wenigsten Ärger unter Linux. Nvidia ist ja teilweise noch eingeschränkt und das selbst im reinen Desktop-Betrieb.

 

[andy_m4]

NV kann genauso wie der Rest der Upstream commiten.

Hör mal auf den Begriff Upstream zu verwenden. Ich weiß, Dir geht unheimlich einer ab dabei. Aber es führt nur zu unnötigen Verwirrungen.

Warum kann NV etwas nicht was der Rest der Welt kann?

Der Stand der Dinge nun so, wie er nun ist. Warum nvidia sich dazu entschieden hat es so zu machen, musst Du nvidia fragen.
Vermutlich geht es vor allem darum möglichst viel Code über Plattformgrenzen hinweg teilen zu können. Daher unterteilt man das eben in System-spezifischen und weitgehend plattformunabhängigen Code.
Hat nvidia ja auch schon früher gemacht. Nur jetzt im Open-Source-Treiber ists halt sichtbar.

BTW: Interne Kernelschnittstellen können sich jederzeit ändern (deswegen sind non-upstream Treiber auch nur ein second class citizen) Schnittstellen Richtung Userspace sind stabil.

Jaja. Wieder irgendwo was gehört und jetzt wird das hier einfach nur in besserwisserischer Manier reproduziert, ohne überhaupt begriffen zu haben, was das bedeutet. Oder gar auf den Kontext (der ist Dir ja sonst sooo wichtig?) einzugehen.
Die Stabilität gegenüber dem Userspace bezieht sich vor allem auf Programme. Denn damit sind in erster Linie Systemaufrufe gemeint.
Bei dem nvidia-Treiber handelt es sich aber um einen Treiber. Und das ganze Gebilde bildet den Treiber. Die Aufteilung ist eine reine Design-Entscheidung.

Die Zweiteilungen in User- und Kernel-space haben die anderen GPU-Treiber genauso.

Ja. Aber da geht die Trennung nicht quer durch den Treiber, sondern es ist in Schichten aufgeteilt.

 

[mibbio]

Vermutlich geht es vor allem darum möglichst viel Code über Plattformgrenzen hinweg teilen zu können. Daher unterteilt man das eben in System-spezifischen und weitgehend plattformunabhängigen Code.

Ein weitere Grund dürfte glaube auch sein, gewisse Informationen zur detailierten Funktionsweise der Hardware oder treiberseitige Limitierungen der Hardware (bspw. künstlich reduzierte FP64-Performance bei Consumerkarten) unter Verschluss zu halten. Mit einem kompletten Open Source Treiber würden sie diese Informationen ja auch offenlegen und man könnte unabhängige Treiber basteln, die diese Limitierungen nicht eingebaut haben.

 

[foofoobar]

Ich weiß, Dir geht unheimlich einer ab dabei.

Was du so alles zu wissen meinst.

Ergänzung (22. Januar 2025)

Ein weitere Grund dürfte glaube auch sein, gewisse Informationen zur detailierten Funktionsweise der Hardware oder treiberseitige Limitierungen der Hardware (bspw. künstlich reduzierte FP64-Performance bei Consumerkarten) unter Verschluss zu halten. Mit einem kompletten Open Source Treiber würden sie diese Informationen ja auch offenlegen und man könnte unabhängige Treiber basteln, die diese Limitierungen nicht eingebaut haben.

Noch ein Grund mehr diesen Dreck zu meiden.