Nachdem ich als X1900XT-Besitzer jahrelang lesen musste, wie überlegen und glückseeligmachend die proprietären Nvidiatreiber sind und weil es preis-/leistungsmäßig keine Alternative zu einer 8800GT gab, bin ich von ATI zu NV gewechselt.
Die Mythen um den überlegenen Windowstreiber waren schnell zerschlagen, tatsächlich hatte ich mit dem ForceWare (neu: GeForce) ebenso ein paar kleinere Probleme, wie zuvor gelegentlich mal bei einem Catalyst-Release. Ansonsten liefern beide Hersteller erstklassige Windowstreiber, die Skalierungsoptionen (insbesondere Fullscreen TV-Out) sind bei ATI besser, egal.
Der proprietäre NV-Linuxtreiber ist tatsächlich sehr performant (was mir persönlich nichts nützt, Dual-boot für Spiele), Compiz läuft gut, aber die Videowiedergabe ist anfällig für Tearing (Vsync nutzt nichts). Ehrlich gesagt, der proprietäre fglrx ist zwar in Spielen etwas langsamer, bietet aber mittlerweile auch alle wichtigen Features und ist genauso stabil.
Jetzt kommt aber der Clou, beide Hersteller können ihren proprietären Crap gern behalten, sobald ich vollumfänglichen Support durch einen freien Treiber haben kann (bei mir: ausreichende Performance für Compiz, TV-Out, beschleunigte Videowiedergabe, PowerPlay). Wenn dazu Code sogar in den Kernel einzieht, umso besser, als Enduser freue ich mich auf den Tag, wo meine HD5870 (HD4870 hat leider vermurkstes PowerPlay, mal sehen ob es noch repariert werden kann) Out-of-the-Box erkannt wird und läuft, wie man es beim Hardwareeinbau unter Linux eben gewohnt ist.
Wollt ich nur gesagt haben und Blog habe ich keins.
Das stimmt, dass CCC von ATI war zum Zeitpunkt meines Wechsels noch bestenfalls als häßliche Baustelle zu bezeichnen. Allerdings wechsle ich die Einstellungen sowieso nicht, einzig Vsync, 4xAA und 16xHQAF habe ich einmalig als Standardvorgabe eingestellt, das geht zur Not auch über die xorg.conf.
Da fällt mir noch was ein, unter Windows gibt es bei NV ja AA-Kompatibilitätsbits, sop dass man beispielsweise in der Ogre-Engine (Jack Keane, Ankh2, ...) AA treiberseitig erzwingen kann, obwohl die Engine (zumindest zu diesem Zeitpunkt) noch kein HDR + AA unterstützt. Gibt es unter Linux auch eine Möglichleit, dem Treiber einen Kompatibilitätsmodus vorzugeben? nHancer (godlike Windows Tool) oder die Spielprofile in der Registry gibt es ja unter Linux nicht.
Ich habe jetzt, nachdem ich seit meiner TNT2 nur auf Nvidia Grafikkarten setzte, wieder mal zu einer ATI 4850 gegriffen. Was man in sachen Linux Unterstützung hört, scheint sich ATI ja druchaus zum positiven entwickeln.
Das ATI Controlcenter verwendet zwar ein hässliches Toolkit, das was man aber einstellen kann funktioniert durchaus intuitiv und problemlos. In all den Jahren in den ich Nvida genutzt habe, habe ich es nicht geschafft Twinview nach meinen Vorstellungen mit dem Tool zu konfigurieren, stattdessen war es immer wieder notwendig die entspechenden Einstellungen manuell in der xorg.conf zu machen.
Als ich die neue ATI installiert hatte, hab einfach mal "naiv" im Controlcenter herumgeklickt, und meine Beiden Bildschrime machten genau das was ich von ihnen erwartete. Kein lesen von Dokumentation notwendig, kein manuelles editiern der xorg.conf.
Ich will die ATI-Treiber nicht zum himmel loben, es gibt durchaus noch Probleme (video tearing, wine, ...), aber es ist bei weitem nicht mehr alles so schlecht wie es noch vor nicht all zu langer Zeit war.
Dort soll er im DRI-Code für eine korrekte Umschaltung der Grafikmodi sorgen.
Ich hab zwar keine Ahnung was dieser Satz heißen soll, aber worum es wirklich geht ist: Der ATOM-BIOS-Parser soll sowohl in den Kernel als auch in die xf86-video-ati und xf86-video-radeonhd einließen. Der Code dient, wie richtig gesagt, zum Umschalten der Grafikmodi. Wichtigster Aspekt dabei ist KMS (Kernel-based-Mode-Setting, für DRM Modesetting). Damit ist es möglich den Rechner direkt beim Booten in den für den Monitor/ das TFT passenden Modus zu wechseln (wie das die Framebuffertreiber wie radeonfb auch schon tun). Der Modus muss später nicht mehr gewechselt werden wenn X.Org startet. Vorteil der Architektur ist es, dass beim Wechsel zwischen VT und X.Org keine Modewechsel mehr stattfinden. Außerdem kämpfen nicht mehr der Framebuffer-Treiber (wie radeonfb) und der DDX-Treiber (wie xf86-video-ati) um die Vorherrschaft an den Rechten der Grafikkarte.
Der Code soll, wie zuvor erwähnt, auch in die DDX-Treiber xf86-video-ati und xf86-video-radeonhd, da diese sonst ohne KMS nicht funktionieren würden.
Bitte nicht immer nur von Phoronix abschreiben, Michael Larabel weiß auch nicht alles. Bessere Quellen sind http://tirdc.livehjournal.com und http://people.freedesktop.org/~cbrill/dri-log/?date=today&channel=radeon bzw. http://people.freedesktop.org/~cbrill/dri-log/?date=today&channel=dri-devel
Sie arbeiten doch längst zusammen und stehen in regem Austausch, es wurde auch überlegt ob der DRI-Implementierung von xf86-video-ati als Basis für den 3D-Support im xf86-video-radeonhd dienen soll. Zusammenlegen werden sie die Projekte wohl eher nicht, da xf86-video-ati auch ältere Karten unterstützt, für die kein Support durch xf86-video-radeonhd vorgesehen ist, vielleicht wird aber eines Tages die Redundanz beseitigt.
Die Mailinglist von xf86-video-radeonhd liefert zu dem Thema einige interessante Beiträge.
Die beiden Projekte arbeiten insofern zusammen dass z.B. Alex Deucher (AMD) Code aus dem xf86-video-ati in xf86-video-radeonhd portiert (EXA, DRI Initialisierung). Derzeit arbeiten auch Entwickler von Novell (die hinter xf86-video-radeonhd stecken) and dem R600 DRM, welcher dann wiederum beiden DDX-Treibern zu Gute. Dave Airlie (Red Hat) beschäftigt sich derzeit mit dem KMS. KMS wird noch Teile von xf86-video-ati für R100 bis R400 Unterstützung erhalten. Möglicherweise werden auch Teile aus den xf86-video-radeonhd in den Kernel portiert (für diejenigen die auf ATOM-BIOS verzichten wollen). Allerdings ist im Kernel "doppelte Funktionalität" nicht so gern gesehen. Von daher hat der ATOM-BIOS-Parser gute Chancen große Teile des xf86-video-radeonhd obsolet zu machen. Da Novell allerdings auf xf86-video-radeonhd für SLES setzt, wird der Treiber wohl immer weiter entwickelt werden.
Mittlerweile fragt man sich aber wirklich, wozu der radeonhd-Treiber noch gut sein soll. Mit dem alten "ati"-Treiber funktionieren auch die neueren Karten mittlerweile wesentlich besser (mehr Features usw.).
Von Christopher Bratusek am Mo, 28. Juli 2008 um 19:48 #
Ausserdem funktionieren neuere karten eben _nicht_ mit ati, z.B. meine X1600 (x startet nicht, d.h. karte wahrscheinlich nicht unterstützt), mit radeonhd allerdings schon. da radeonhd aber bei jedem fenster erstellen noch flackert beibe ich vorerst bei fglrx.
Die sollte aber gehen, handelt sich wohl um ein Kompatibilitätsproblem. radeonhd hängt featuremäßig eben extrem hinterher, viel mehr als einfache 2D-Beschleunigung geht noch nicht. ati/radeon hat dagegen bei R500ern schon OpenGL und hardwarebeschleunigtes EXA mit RENDER.
Von Christopher Bratusek am Mo, 28. Juli 2008 um 20:22 #
Meine x1200 geht mit ati, so'n Mist.
Ich kann mit radeonhd und dem cairo-compositing-manager auch einen 3d desktop haben, von daher hinkt radeonhd nicht so weit hinterher. Die Leistung ist spürbar schlechter als mit fglrx aber das legt sich hoffentlich bald.
Das liegt daran, weil radeonhd eben keine richtige EXA- oder RENDER-Beschleunigung hat. Das bedeutet, das Compositing wird per Software gemacht! Dann gibt's auch kein Xv (viel Spaß beim Videos gucken), Skalieren auf DFPs wird nicht unterstützt, beschleunigtes OpenGL erst recht nicht.. nee, nee, da sollte man wirklich lieber den ati/radeon nehmen. Damit funktioniert auch Compiz und einfachere Spiele.
Ist ja okay, aber mir ging es darum, die beiden Opensource-Treiber zu vergleichen. Da hinkt radeonhd so weit hinterher, dass man damit die Grafikkarte nicht sinnvoll nutzen kann. Man ist besser bedient, wenn man sich eine alte Radeon 8xxx/9xxx einbaut (und ati/radeon verwendet), die bietet dann bessere Performance und mehr Features als eine neuere Karte mit radeonhd.
Ich finden radeon/ati wesentlich besser weil der radeonhd meinen Monitor gar nicht erkannt (mit dem einen Monitor startet er gar nicht) und die Features des radeonhd sind wirklich schwach
Von Michael Lehmeier am Di, 29. Juli 2008 um 08:50 #
In der Tat geht jetzt mit dem ati/radeon Treiber auch meine HD3450. Vor dem gestrigen Upgrade ging es nur mit radeonhd. Okay, xv scheint noch nicht zu funktionieren, aber ich kann warten. Was aber lustig ist: Nach dem, was ich sehen kann, hat der ati/radeon Treiber den selben Cursor-bug, den ich schon bei radeonhd beobachten konnte. (gelegentlich wird der Cursor zu einem pixeligen Strich, das verschwindet aber wieder) Sieht so aus, als ob da doch einiges zusammen entwickelt wird.
Mit dieser Aktion verliert doch X.Org seine Plattformunabhängigkeit oder? Da es nur Linux-exklusiv sein wird, werden Solaris, FreeBSD, NetBSD, OpenBSD etc. ausgeschlossen werden oder?
Ich bin kürzlich bei meinem Notebook (mit x1400) von fglrx auf xf86-video-ati umgestiegen. Auch wenn sich fglrx in den letzten Monaten recht gut entwickelt hat, ist er mir immer noch zu instabil und ich habe bisher keine Version des Treibers gefunden die man als voll funktionstüchtig bezeichnen kann. Bei der neuesten Version bekomme ich beim mode-setting ein korruptes X-Display um muss X neu starten. Die Versionen vorher haben bei mir immer Probleme bei der Videodarstellung gemacht (tearing) und bevor AMD textured video implementiert hat konnte man mit dem Treiber so gut wie keine Videos per xv anschaun ausser man lässt sie vom Player nicht auf Vollbild skalieren. Bisher läuft xf86-video-ati wirklich ziemlich gut, alles was man dazu braucht ist ein Kernel der Serie 2.6.26 und einen RC von mesa 7.1. Zum ersten Mal sehe ich nach einem suspend-to-ram ein Bild auf dem Bildschirm, was ich mit dem fglrx nie hinbekommen habe. Wenn noch das powerplay fertig implementiert ist bin ich wirklich zufrieden.
Auch wenn AMD hier einen guten Schritt in die richtige Richtung macht ziehe ich bei den Grafikkarten wegen der Treiber-Unterstützung weiterhin nvidia vor. Zumindest im Desktop-Bereich hatte ich nie Probleme mit dem nvidia-Treiber unter Linux. Wenn man fglrx im Vergleich dazu anschaut wird das meiner Meinung nach wirklich peinlich für AMD.
Das ist klar. Aber nur weil OpenGL draufsteht ist das nicht unbedingt toll und schnell. Die Video-Ausgabe über OpenGL ist weit weniger performant als über xv bzw. textured xv.
Konkretes Beispiel: 720p auf meinem T60 (T7200, x1400) mit fglrx und mplayer -vo gl[2] läuft nicht flüssig, mit textured xv pendelt es sich bei 30% cpu Last ein. Und bevor AMD textured xv halbwegs in den Treiber eingebaut hat war das skalierte Bild nicht zu gebrauchen (extreme Block-Bildung)
Die Mythen um den überlegenen Windowstreiber waren schnell zerschlagen, tatsächlich hatte ich mit dem ForceWare (neu: GeForce) ebenso ein paar kleinere Probleme, wie zuvor gelegentlich mal bei einem Catalyst-Release. Ansonsten liefern beide Hersteller erstklassige Windowstreiber, die Skalierungsoptionen (insbesondere Fullscreen TV-Out) sind bei ATI besser, egal.
Der proprietäre NV-Linuxtreiber ist tatsächlich sehr performant (was mir persönlich nichts nützt, Dual-boot für Spiele), Compiz läuft gut, aber die Videowiedergabe ist anfällig für Tearing (Vsync nutzt nichts). Ehrlich gesagt, der proprietäre fglrx ist zwar in Spielen etwas langsamer, bietet aber mittlerweile auch alle wichtigen Features und ist genauso stabil.
Jetzt kommt aber der Clou, beide Hersteller können ihren proprietären Crap gern behalten, sobald ich vollumfänglichen Support durch einen freien Treiber haben kann (bei mir: ausreichende Performance für Compiz, TV-Out, beschleunigte Videowiedergabe, PowerPlay). Wenn dazu Code sogar in den Kernel einzieht, umso besser, als Enduser freue ich mich auf den Tag, wo meine HD5870 (HD4870 hat leider vermurkstes PowerPlay, mal sehen ob es noch repariert werden kann) Out-of-the-Box erkannt wird und läuft, wie man es beim Hardwareeinbau unter Linux eben gewohnt ist.
Wollt ich nur gesagt haben und Blog habe ich keins.
Da fällt mir noch was ein, unter Windows gibt es bei NV ja AA-Kompatibilitätsbits, sop dass man beispielsweise in der Ogre-Engine (Jack Keane, Ankh2, ...) AA treiberseitig erzwingen kann, obwohl die Engine (zumindest zu diesem Zeitpunkt) noch kein HDR + AA unterstützt. Gibt es unter Linux auch eine Möglichleit, dem Treiber einen Kompatibilitätsmodus vorzugeben? nHancer (godlike Windows Tool) oder die Spielprofile in der Registry gibt es ja unter Linux nicht.
Was man in sachen Linux Unterstützung hört, scheint sich ATI ja druchaus zum positiven entwickeln.
Das ATI Controlcenter verwendet zwar ein hässliches Toolkit, das was man aber einstellen kann funktioniert durchaus intuitiv und problemlos.
In all den Jahren in den ich Nvida genutzt habe, habe ich es nicht geschafft Twinview nach meinen Vorstellungen mit dem Tool zu konfigurieren, stattdessen war es immer wieder notwendig die entspechenden Einstellungen manuell in der xorg.conf zu machen.
Als ich die neue ATI installiert hatte, hab einfach mal "naiv" im Controlcenter herumgeklickt, und meine Beiden Bildschrime machten genau das was ich von ihnen erwartete. Kein lesen von Dokumentation notwendig, kein manuelles editiern der xorg.conf.
Ich will die ATI-Treiber nicht zum himmel loben, es gibt durchaus noch Probleme (video tearing, wine, ...), aber es ist bei weitem nicht mehr alles so schlecht wie es noch vor nicht all zu langer Zeit war.
Ich hab zwar keine Ahnung was dieser Satz heißen soll, aber worum es wirklich geht ist: Der ATOM-BIOS-Parser soll sowohl in den Kernel als auch in die xf86-video-ati und xf86-video-radeonhd einließen. Der Code dient, wie richtig gesagt, zum Umschalten der Grafikmodi. Wichtigster Aspekt dabei ist KMS (Kernel-based-Mode-Setting, für DRM Modesetting). Damit ist es möglich den Rechner direkt beim Booten in den für den Monitor/ das TFT passenden Modus zu wechseln (wie das die Framebuffertreiber wie radeonfb auch schon tun). Der Modus muss später nicht mehr gewechselt werden wenn X.Org startet.
Vorteil der Architektur ist es, dass beim Wechsel zwischen VT und X.Org keine Modewechsel mehr stattfinden. Außerdem kämpfen nicht mehr der Framebuffer-Treiber (wie radeonfb) und der DDX-Treiber (wie xf86-video-ati) um die Vorherrschaft an den Rechten der Grafikkarte.
Der Code soll, wie zuvor erwähnt, auch in die DDX-Treiber xf86-video-ati und xf86-video-radeonhd, da diese sonst ohne KMS nicht funktionieren würden.
Bitte nicht immer nur von Phoronix abschreiben, Michael Larabel weiß auch nicht alles. Bessere Quellen sind http://tirdc.livehjournal.com und http://people.freedesktop.org/~cbrill/dri-log/?date=today&channel=radeon bzw. http://people.freedesktop.org/~cbrill/dri-log/?date=today&channel=dri-devel
Die Mailinglist von xf86-video-radeonhd liefert zu dem Thema einige interessante Beiträge.
Ich kann mit radeonhd und dem cairo-compositing-manager auch einen 3d desktop haben, von daher hinkt radeonhd nicht so weit hinterher. Die Leistung ist spürbar schlechter als mit fglrx aber das legt sich hoffentlich bald.
http://wiki.x.org/wiki/RadeonFeature
Okay, xv scheint noch nicht zu funktionieren, aber ich kann warten.
Was aber lustig ist: Nach dem, was ich sehen kann, hat der ati/radeon Treiber den selben Cursor-bug, den ich schon bei radeonhd beobachten konnte. (gelegentlich wird der Cursor zu einem pixeligen Strich, das verschwindet aber wieder)
Sieht so aus, als ob da doch einiges zusammen entwickelt wird.
Mit dieser Aktion verliert doch X.Org seine Plattformunabhängigkeit oder? Da es nur Linux-exklusiv sein wird, werden Solaris, FreeBSD, NetBSD, OpenBSD etc. ausgeschlossen werden oder?
Auch wenn sich fglrx in den letzten Monaten recht gut entwickelt hat, ist er mir immer noch zu instabil und ich habe bisher keine Version des Treibers gefunden die man als voll funktionstüchtig bezeichnen kann. Bei der neuesten Version bekomme ich beim mode-setting ein korruptes X-Display um muss X neu starten. Die Versionen vorher haben bei mir immer Probleme bei der Videodarstellung gemacht (tearing) und bevor AMD textured video implementiert hat konnte man mit dem Treiber so gut wie keine Videos per xv anschaun ausser man lässt sie vom Player nicht auf Vollbild skalieren.
Bisher läuft xf86-video-ati wirklich ziemlich gut, alles was man dazu braucht ist ein Kernel der Serie 2.6.26 und einen RC von mesa 7.1. Zum ersten Mal sehe ich nach einem suspend-to-ram ein Bild auf dem Bildschirm, was ich mit dem fglrx nie hinbekommen habe. Wenn noch das powerplay fertig implementiert ist bin ich wirklich zufrieden.
Auch wenn AMD hier einen guten Schritt in die richtige Richtung macht ziehe ich bei den Grafikkarten wegen der Treiber-Unterstützung weiterhin nvidia vor. Zumindest im Desktop-Bereich hatte ich nie Probleme mit dem nvidia-Treiber unter Linux. Wenn man fglrx im Vergleich dazu anschaut wird das meiner Meinung nach wirklich peinlich für AMD.
Konkretes Beispiel: 720p auf meinem T60 (T7200, x1400) mit fglrx und mplayer -vo gl[2] läuft nicht flüssig, mit textured xv pendelt es sich bei 30% cpu Last ein.
Und bevor AMD textured xv halbwegs in den Treiber eingebaut hat war das skalierte Bild nicht zu gebrauchen (extreme Block-Bildung)