Die Basics beherrscht der freie Radeon Treiber schon recht brauchbar. Sogar Energiespar-Features unterstützt er mittlerweile. Für den anspruchslosen Desktop Nutzer druchaus eine brauchbare Alternative.
Für speziellere Aufgaben muss er sich dann doch leider recht oft den Binär-Blobs von ATI und Nvidia geschlagen geben. Bei OpenGL-Performance, Video-Beschleunigung, Sound über HDMI, ... sieht es bei den freien Treibern dann leider recht mager aus.
Ist ja auch super, wenn du deine Grafikkarte nur für Grafik-IO nutzt. Manche Menschen benutzen die allerdings auch für GPGPU oder zum Zocken und da siehts düster aus auch mit Intel. Und wir wollen uns nichts vormachen, der fglrx von AMD war und ist (und wird es wohl auch immer sein) um den Faktor 10 beschissener. Unterm Strich bleibt da nur noch der binäre Treiber von Nvidia übrig. Denn er unterstützt: - CUDA/OpenCL - Funktioniert mit jedem Xorg/Kernel release - Ist momentan der schnellste Treiber von ALLEN - Hat den größten Funktionsumfang, von ALLEN Treibern - Subjektiv scheint er auch der stabilste von allen zu sein Ich persönlich hätte den Treiber auch lieber quelloffen. Aber momentan bin ich zumindest damit zufrieden, dass er funktioniert und alle Funktionen, die man von Windows her kennt unterstützt. Das ist bei den ganzen andern Treiber einfach nicht der Fall. Momentan ist auch nicht abzusehen wann sich daran was ändert. Außerdem möchte ich noch erwähnen, dass die ganzen anderen Treiber auch noch heftige Grafikfehler mit OpenGL Games oder Software. Ich darf daran erinnern, dass AMD beim Release von Doom 3 erst nen völlig neuen Treiber releasen mussten, weil ihr OpenGL support so unfassbar schlecht war und ist.
Dann darfst Du das auch nicht so allgemein formulieren. Dann gibt es da auch mehrere "stabile" Nvidia-Treiber. Und gerade die Legacy-Treiber sind oft diejenigen, die mit neuesten Distros nichts als Probleme haben, da meist Xorg zu neu ist und Nvidia diese Treiber noch nicht angepasst hat bzw. gar nicht mehr anpassen möchte.
Und wenn man das weiß und noch diese nicht durch die Linux-Community fixbaren Nvidiatreiber-Sicherheitslücken sieht, dann bemerkt man sehr rasch, wie wichtig Nouveau eigentlich ist.
Eine freie Alternative ist immer die schönste Lösung und ich wollte auch nicht sagen, dass der Nouveau-Treiber unwichtig ist. Es ist nur so, dass er momentan leider noch nicht für jeden User das die Lösung aller Grafikprobleme ist. Ich meine, eigentlich teilen wir als User alle die selben Probleme. Entweder man hat nen freien Treiber mit halber Funktionalität oder all die Nachteile von den closed source Treibern (wobei dort nur der von NVIDIA brauchbar ist).
Ich kenne mich mit dem Kernel nicht aus und weiß nicht wie er die Module nachlädt, dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist. Wenn meine Programme Plugins oder externe Module nachladen, dann haben sie nur wohldefinierte Speicherbereiche auf die sie zugreifen können. Wenn es der NVIDIA BLOB kann, dann können es auch sicher andere Module, ob BLOB oder nicht BLOB.
Die Module laufen im Ring0, sprich sind Teil des Kernels. Ansonsten könntest Du viele Treiber oder Subsysteme gar nicht in Module auslagern. Sprich Du hast einen großen monolithischen Kernel in den Distributionen. Für einen kleineren Memory Footprint würdest einen auf Dein System zugeschnitten Kernel kompilieren müssen.
Das Sandbox Prinzip oder ähnliche Mechanismen zu Trennung sind sicher oft möglich, wann man nicht sehr auf Geschwindigkeit angewiesen ist.
Bei NVidia ergibt sich aus Binary-Only das größere Problem, die Kernel Community kann keinen Code Review machen. Daher ist es eher eine Frage ob eine Sandbox für Binary Module sinnvoll oder sogar notwendig ist.
Von -.,-,-,-,.-,-., am Do, 2. August 2012 um 20:56 #
Natürlich ist der Kernel daran nicht ganz unschuldig. Der Kernel dürfte den Blob überhaupt nicht laden, weil der NVidia-Treiber unfrei ist. Na ja, wenigstens sind die Sicherheitslücken frei Haus.
Und in welcher Sprache sind deine Programme (und Plugins) geschrieben? Java, Python o.Ä.? Wenn sie in C/C++ geschrieben sind muss ich dir mitteilen, dass nachgeladene Plugins Zugriff auf den gesamten Speicher deines Programmes haben (wenn du nicht gerade eine Art Sandboxing verwendest).
Wenn du schon nicht weißt wie ein Kernel seine Module bzw. Treiber lädt, warum glaubst du dann es wäre eine gute Idee Schuldzuweisungen auszusprechen??
Die Xorg Entwickler sind gerade erst so weit ( kurz davor oder danach ), dass der Xorg Server ohne root User läuft, daher kommen wahrscheinlich die Berechtigungen auf /dev/nvidia0.
Auch wenn's langsam alt wird: "Fuck you, Nvidia!"
Und was für ne GPU hast du? Sag jetzt nicht GeForce XYZ ...
Nee, ich habe natürlich eine von Intel! Bin ja nicht blöd.
Ich hab seit 1 Woche ne ATi und bin echt erstaunt wie gut die freien Treiber funktionieren. -> nie wieda Nvidia
Naja, gut ist relativ.
Die Basics beherrscht der freie Radeon Treiber schon recht brauchbar. Sogar Energiespar-Features unterstützt er mittlerweile. Für den anspruchslosen Desktop Nutzer druchaus eine brauchbare Alternative.
Für speziellere Aufgaben muss er sich dann doch leider recht oft den Binär-Blobs von ATI und Nvidia geschlagen geben. Bei OpenGL-Performance, Video-Beschleunigung, Sound über HDMI, ... sieht es bei den freien Treibern dann leider recht mager aus.
Ist ja auch super, wenn du deine Grafikkarte nur für Grafik-IO nutzt.
Manche Menschen benutzen die allerdings auch für GPGPU oder zum Zocken und da siehts düster aus auch mit Intel.
Und wir wollen uns nichts vormachen, der fglrx von AMD war und ist (und wird es wohl auch immer sein) um den Faktor 10 beschissener.
Unterm Strich bleibt da nur noch der binäre Treiber von Nvidia übrig. Denn er unterstützt:
- CUDA/OpenCL
- Funktioniert mit jedem Xorg/Kernel release
- Ist momentan der schnellste Treiber von ALLEN
- Hat den größten Funktionsumfang, von ALLEN Treibern
- Subjektiv scheint er auch der stabilste von allen zu sein
Ich persönlich hätte den Treiber auch lieber quelloffen. Aber momentan bin ich zumindest damit zufrieden, dass er funktioniert und alle Funktionen, die man von Windows her kennt unterstützt. Das ist bei den ganzen andern Treiber einfach nicht der Fall. Momentan ist auch nicht abzusehen wann sich daran was ändert.
Außerdem möchte ich noch erwähnen, dass die ganzen anderen Treiber auch noch heftige Grafikfehler mit OpenGL Games oder Software. Ich darf daran erinnern, dass AMD beim Release von Doom 3 erst nen völlig neuen Treiber releasen mussten, weil ihr OpenGL support so unfassbar schlecht war und ist.
Grüße
" Funktioniert mit jedem Xorg/Kernel release"
Ha, ha, ha.
Zumindest mit den nicht Entwicklerversionen.
Aber das ist immernoch mehr als das bei AMD der Fall ist.
Dann darfst Du das auch nicht so allgemein formulieren.
Dann gibt es da auch mehrere "stabile" Nvidia-Treiber.
Und gerade die Legacy-Treiber sind oft diejenigen, die mit neuesten Distros nichts als Probleme haben, da meist Xorg zu neu ist und Nvidia diese Treiber noch nicht angepasst hat bzw. gar nicht mehr anpassen möchte.
Und wenn man das weiß und noch diese nicht durch die Linux-Community fixbaren Nvidiatreiber-Sicherheitslücken sieht, dann bemerkt man sehr rasch, wie wichtig Nouveau eigentlich ist.
Eine freie Alternative ist immer die schönste Lösung und ich wollte auch nicht sagen, dass der Nouveau-Treiber unwichtig ist.
Es ist nur so, dass er momentan leider noch nicht für jeden User das die Lösung aller Grafikprobleme ist. Ich meine, eigentlich teilen wir als User alle die selben Probleme.
Entweder man hat nen freien Treiber mit halber Funktionalität oder all die Nachteile von den closed source Treibern (wobei dort nur der von NVIDIA brauchbar ist).
Ich kenne mich mit dem Kernel nicht aus und weiß nicht wie er die Module nachlädt, dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist. Wenn meine Programme Plugins oder externe Module nachladen, dann haben sie nur wohldefinierte Speicherbereiche auf die sie zugreifen können. Wenn es der NVIDIA BLOB kann, dann können es auch sicher andere Module, ob BLOB oder nicht BLOB.
Die Module laufen im Ring0, sprich sind Teil des Kernels. Ansonsten könntest Du viele Treiber oder Subsysteme gar nicht in Module auslagern. Sprich Du hast einen großen monolithischen Kernel in den Distributionen. Für einen kleineren Memory Footprint würdest einen auf Dein System zugeschnitten Kernel kompilieren müssen.
Das Sandbox Prinzip oder ähnliche Mechanismen zu Trennung sind sicher oft möglich, wann man nicht sehr auf Geschwindigkeit angewiesen ist.
Bei NVidia ergibt sich aus Binary-Only das größere Problem, die Kernel Community kann keinen Code Review machen. Daher ist es eher eine Frage ob eine Sandbox für Binary Module sinnvoll oder sogar notwendig ist.
Natürlich ist der Kernel daran nicht ganz unschuldig.
Der Kernel dürfte den Blob überhaupt nicht laden, weil der NVidia-Treiber unfrei ist.
Na ja, wenigstens sind die Sicherheitslücken frei Haus.
Und in welcher Sprache sind deine Programme (und Plugins) geschrieben? Java, Python o.Ä.? Wenn sie in C/C++ geschrieben sind muss ich dir mitteilen, dass nachgeladene Plugins Zugriff auf den gesamten Speicher deines Programmes haben (wenn du nicht gerade eine Art Sandboxing verwendest).
Wenn du schon nicht weißt wie ein Kernel seine Module bzw. Treiber lädt, warum glaubst du dann es wäre eine gute Idee Schuldzuweisungen auszusprechen??
Grüße,
unreal
> dennoch denke ich, dass der Kernel selbst da nicht ganz unschuldig ist.
Völlig korrekt, denn mit einem Microkernel wäre das nicht passiert.
lasset das flaming beginnen..
Welche Nutzer haben denn für gewöhnlich Zugriff auf /dev/nvidia0?
Alle die, die Grafikkarte nutzen?
crw-rw---- 1 root video 195, 0 2. Aug 15:43 /dev/nvidia0
Könnte man denn hier nicht den Hebel ansetzen und für die Gruppe video Sonderprivilegien einsetzen? (Entschuldige die unqualifizierte Frage.)
Die Xorg Entwickler sind gerade erst so weit ( kurz davor oder danach ), dass der Xorg Server ohne root User läuft, daher kommen wahrscheinlich die Berechtigungen auf /dev/nvidia0.
Ist dann also auch der X.org mit dafür verantwortlich? Oder verstehe ich da jetzt was falsch?