Hi Sebastian, Am 10.05.2012 00:54, schrieb Sebastian Siebert:
Das war für mich immer und auch heute noch ein No-Go. Ein Treiber hat einfach bei jeder Kernel-Version zu funktionieren. Wo kommen wir den hin, wenn die Firma sagt, ja aber wir unterstützen für openSUSE 12.1 nur den Kernel 3.1.x. Alle anderen Kernel-Versionen sind Tabu und auch nicht freigegeben. Also, auf eigenes Risiko. Und diejenigen, die auf eine neue Kernel-Version angewiesen sind, schauen in die Röhre, wenn sie nicht gerade Kernel-Hacker sind. :-(
soweit ich weiß, werden diese NVidia-Treiber-RPMs für openSUSE von openSUSE selber gebaut und da gibt es schon lange LEIDER die Devise: Wir unterstützen nur den Kernel, mit dem das entsprechende Release initial gebaut wurde. Das sieht man in vielen Repositories (Hardware) wo Funktionen neuerer Kernel (z.B. WLAN-Treiber) mühsam für die Release-Kernel herausoperiert und dann einzeln bereitgestellt werden. Welche ein Aufwand, statt einfach den neusten STABLE-Kernel direkt zu unterstützen. Funkt wunderbar und ich praktiziere das seit mehreren Jahren. Aber das sind eben eingefahrene Ideen denen gefolgt wird, weil es immer schon so war...
Da haben die ATIs es mit der Lösung von Sebastian Siebert's viel besser, der den aktuellen ATI-Treiber immer für den aktuellen STABLE-Kernel baut. Schöne Sache und ich nutze diesen Komfort auf einem Notebook.
Das war auch die Intention dieses Rebuild-Skript und leistet bisher gute Dienste. Klagen habe ich schon lange nicht mehr gehört. ;-)
Ansonsten bin ich wegen VDPAU und CUDA eben komplett NVidia-geprägt. Bei ATI wird das wohl in meinem Leben nichts mehr...
Öhm, ich weiß jetzt nicht, ob du etwas von XvBA + VA-API gehört hast? http://www.sebastian-siebert.de/2011/09/11/opensuse-hardware-videobeschleuni...
Ich kenne deinen Artikel und hatte etwa zur gleichen Zeit ziemlich mit dem Thema VA-API etc. rumgespielt, aber eben zusammen mit dem i5 Clarkdale, dessen interne Graphik auch per VA-API unterstützt wird. Leider hätte ich damals aber sowohl MPLAYER als auch ffmpeg für VA-API kompilieren müssen und den Aufwand habe ich mir dann nicht gegeben. Vor allem wenn man bei Packman sieht, wie oft es neue MPLAYER-Patches gibt und dann immer wieder diesen Akt - nein Danke. Auch die Tools auf MPLAYER unterstützen VA-API nicht richtig, evtl. vielleicht über versteckte Tricks von denen ich noch nichts gelesen habe. Ich nutze gerne den SMPlayer und dort gibt es bis heute noch immer nicht die Option VA-API auszuwählen. VDPAU dagegen funktioniert überall problemlos auf Kopfdruck. Selbst der SMPlayer2 als Frontend zum Mplayer2, der VA-API besser unterstützen soll, als der erste MPlayer, ist immer noch keine VA-API-Option in Sichtweite, als ich da letzte Mal danach suchte. VDPAU springt einem sofort ins Gesicht. (Ja, ich weiß, Mplayer2 ist nur ein Branch, aber ich bin kürzlich umgestiegen, da der Mplayer2 mittlerweile bei mir stabiler läuft als der Erste)
Dies funktioniert bei mir mit VLC, mplayer und Totem mit dem ffmpeg Decoder (mit eingeschalteter Hardware-Decoding für H.264 und VC-1) richtig gut und nutze dies regelmäßig (VLC-Player) über meinen Flat-TV (1920x1080) via HDMI. Tatsache ist, dass ich meinen DVD-Player (ja, der steht noch unter meinem Fernseher) seitdem nicht mehr nutze. ;-)
VLC hatte ich dann auch mal für VA-API in der von dir empfohlenen Version versucht (wird dort ja eher generisch eingeschaltet ohne die eingeführten Techniken also VA-API, VDPAU zu erwähnen) aber keine signifikante Änderung mit oder ohne Hardwareunterstützung finden können.
Und was mit der CUDA-Konkurrenz angeht, unterstützt AMD jetzt auch OpenCL. Und das schon seit AMD Catalyst 11.12 (Dezember 2011) für alle AMD Radeon HD, AMD FireStream, AMD Mobility Radeon HD und AMD Mobility FirePro Serien.
http://developer.amd.com/zones/openclzone/Pages/default.aspx
Auch eine kleine Portierungsanleitung von CUDA auf OpenCL stellt AMD zur Verfügung: http://developer.amd.com/zones/OpenCLZone/programming/pages/portingcudatoope...
Um OpenCL muß ich mich noch intensiver kümmern, aber was ich so von Akteuren in diesem Spiel höre und in diversen Artikeln lese, richtet sich OpenCL eher weniger an Grapfikprozessoren sondern eher an normale CPUs und als Sonderlocke dann vielleicht die Graphikkarten (Ich glaube auf Phoronix hab' ich's mal gelesen). Und solange BOINC das nicht unterstützt, ist das sowieso für mich tot.
Hm, das ist ja bemerkenswert. Man liest bei manchen Menschen, dass sie auf AMD schimpft, wenn etwas nicht funktioniert und zu NVIDIA wechseln wollen. Dann bei NVIDIA angekommen, bleiben sie bei einem Treiber-Fehler ruhig und können auf einmal abwarten. Ja, in der Tat ist das bemerkenswert. :-)
Wie gesagt/geschrieben, ich kenne beide Welten AMD und NVidia. Bevor ich deinen Service des RPM-Baus gesehen habe, hatte ich auch bei ATI den neusten Treiber mit Bordmitteln installiert und fand den Prozeß dann schon sehr gewöhnungsbedürftig und hakellig. Besonders die Pflicht, den alten Treiber vorher manuell deinstallieren und wieder durchstarten zu müssen, ist schon vorsintflutlich, oder? Das ginge besser. (War der 8.schlag-mich-tot vom Sommer/Herbst oder so, als ich das Notebook einrichtete) BTW, das besagte AMD/ATI-Notebook, etwa 1 Jahr alt mit 4250er Graphik wird dann demnächst dank AMD-Releasepolitk kaum noch unterstützt und zum Edelschrott geworfen. Bei NVidia werden meine alten 6er Karten von 2005 heute noch vom neusten Treiber unterstützt. Ein weiterer Baustein in meinen schlechten Erfahrungen mit ATI. Gerne hätte ich deinen Service der vorbereiteten RPMs auch für NVidia-Treiber, aber ich sehe schon, dein Herz schlägt hier für ATI und ich weiß gar nicht, ob AMD sich bewußt ist, was sie mit dir haben :-). Viele Grüße Ralf -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org