Der Nvidia Treiber meines wissens nach schon. Schau mal bei nvidia.com oben in der leiste: "Technologies" -> "OpenCL". AMD hat ja auch angekuendigt OCL unterstuetzen zu wollen.
Hast du die Seite gelesen? Soweit ich das sehe, verkündet Nvidia da, dass sie OpenCL ganz toll finden, damit grad rumspielen und das demnächst vielleicht irgendwann mal unterstützen werden. Abgesehen davon löst OpenCL nicht die besagte Lizenzproblematik, denn man muss ja immer noch eigenen Code schreiben, der die patentieren Codecs implementiert.
wenn ich das richtig verstanden hab, hat nvidia denn decoder in hardwaregegossen auf der grafikkarte, so muss der programmieren den "film" nur noch an die API des "Nvidia-graka-decoders" schicken und der verarbeitet den "film" dann.
Also brauch das Programm keinen decoder mehr, sondern nur noch eine schnittstelle zur API
Korrekt, die GPU besorgt das Decodieren selbständig und Nvidia hat schon Gebühren bezahlt. Problem gelöst.
VDPAU rockt übrigens jetzt schon obwohl es noch in der Test-Phase ist. Nachdem AMD es schon ewig nicht hinbekommt Video-Ausgabe über simples Xv ohne tearing hinzubekommen zieht Nvidia einfach dieses Ass aus dem Ärmel. Ich hatte mich lange genug mit einer AMD Karte rumgeschlagen und auf vernünftige Treiber für Video gucken gewartet. Jetzt eine billige Nvidia drin, alle Probleme gelöst. CPU-Auslastung mit VDPAU bei HD-Auflösungen: nahe Null.
"Korrekt, die GPU besorgt das Decodieren selbständig und Nvidia hat schon Gebühren bezahlt. Problem gelöst."
Welche GPUs betrifft das überhaupt? Und: Seit wann bezahlt NVidia für meine ATI-Karte die Lizenzgebühren? Falls nicht, ab in den "Trash" mit dieser Idee.
Bei Nvidia ab der 8er Serie, bei IGPs wie der 8200 bin ich mir nicht sicher.
VDPAU ist eine offene API, Intel plant wohl schon Unterstützung, ob AMD mal aus dem Quark kommt ist eine andere Frage. Eine neue API war dringend nötig, da die bisherigen (XV & Co) für GPU-Decoding nutzlos sind.
Nanana, VDPAU ist eine saubere API, die nicht nur für NVIDIA Karten ausgelegt ist, auch für den intel Treiber ist eine implementierung in arbeit, ati überlegt auch, ob sie den fglrx damit ausstatten sollen. Sogar der neue propritäre S3 Treiber unterstützt VDPAU. Was den nv Treiber angeht, der wird nie mehr können als 2D, mit noveau könntest du in Zukunft ein bisschen Glück haben, aber diesen Masochismus würde ich mir nicht antun, der Nvidia Treiber ist imho momentan der beste OpenGL Treiber für Linux. Mit DRI2 und Gallium3D mit LLVM könnte einer der beiden freien ati treiber mal richtig gut werden.. leider fürchte ich, dass bis dahin die Hardware, für die das zutrifft völlig veraltet ist - oder es wird alle Hardware unterstützt, dafür aber nur mäßig. Eher könnte der fglrx aufhohlen, aber das glaube ich auch nicht, jetzt wo AMD das Entwicklungsteam zusammenstreicht.
nun - der neuste ATI Treiber (9.3) ist eine derartige Verbesserung, daß ich da keine Befürchtungen habe - und was veraltete Hardware angeht, die Tage gabs die Doku für R700 - also die derzeit aktuelle Architektur. Sieht also gut aus.
das meine ich mit dem zweiten Nebensatz, während die alte hardware noch nicht richtig läuft (keine Shader, um den Faktor 10 bis 20 schlechtere Performance) kommen die Entwickler kaum hinterher, Support für die neuen Karten zu implementieren- die R600 Doku gab's schon letztes Jahr und es gibt auf den Karten noch immer kein beschleunigtes 3D. Ich würd ja gerne bei der Treiberentwicklung helfen, wenn ich wüsste wie :-( Der Mangel an Entwicklern wird aber dadurch nicht besser, dass gleich zwei verschiedene Treiber für die selbe Hardware parallel entwickelt werden..
Für erweiterte Opengl funktionen wie Shader und FBOs wird ein memory manager benötigt. Da GEM jetzt im kernel enthalten ist, rechne ich das bis ende diesen jahres die ersten opensource treiber rauskommen, welche opengl 2.x und eventuell auch schon opengl 3.x mit dem MESA opengl stack unterstützen.
Was hat denn ein Memory Manager bitte mit Shadern zu tun? Dafür brauchts vielmehr eine anständige Compilerarchitektur. Da ist zwar mit der LLVM-Integration was in Aussicht, aber bis das auf dem Niveau der proprietären Treiber läuft, ist noch einiges mehr an Arbeit nötig.
"Ich würd ja gerne bei der Treiberentwicklung helfen, wenn ich wüsste wie."
Es gibt eine Xorg-Sponsorship. Vielleicht hast Du ja irgendwann einmal einen sehr guten Job, dann denkst Du vielleicht einmal daran. :-)
Ich sehe diese Seite allerdings heute auch das erste Mal, weil ich erst vor ein paar Minuten überhaupt danach gesucht habe. Was die eigentlichen Donations anbelangt, so verstehe ich aber leider nur "Bahnhof": http://www.x.org/wiki/SponsorshipPage Das sieht nicht so aus, als würde man kleine Spenden brauchen (?).
> der Nvidia Treiber ist imho momentan der beste OpenGL Treiber für Linux
Hust. Ich verwende nvidia-Karten seit genau 2003. Wenn ich daran denke wie oft irgedwas nicht funktionierte was definitiv auf nvidia zurückzuführen war, wäre ich persönlich mehr als vorsichtig denen irgendwas positives zu unterstellen. Zumindest unter Linux ist die Treiberqualität bestenfalls schwer-scheiße. Leider brauche ich 3D-Beschleunigung aus beruflichen Gründen. Dennoch tut es weh zu sehen wie immer mehr Firlefanz plötzlich in GPU's berechnet werden soll die so transparent sind die Omas extra-dicker Thrombosestrumpf.
Durch eine Erweiterung der Lizenzvereinbarung zwischen Microsoft und MPEG LA sei es deshalb auch unter Linux möglich, H.264 zu nutzen. Doch Unklarheiten machen einen Einsatz problematisch, denn laut einhelliger Meinung gilt diese Vereinbarung nur für Novell-Nutzer. Nur Anwender, die Moonlight direkt von Novell heruntergeladen haben, sollen von der Kooperation betroffen sein. Für andere Distributoren oder OEM-Hersteller stellt sich die Sache schwieriger dar. Die Nutzung der Codecs wird unklar und eine Patentklage der MPEG LA oder Microsoft durchaus wahrscheinlich.
noch mehr Verwirrung was man jetzt darf oder nicht (ist opensuse in dem fall novell?) Ich glaub da is mir lieber etwas is MS only als so eine Lösung
Vielleicht sollten die "Kreateure" dieser Pseudolösung ganz einfach einmal mit einem offiziellen Brief bei der MPEG-LA nachfragen. Wenn sie es in den nächsten 14 Tagen nicht tun, werde ich es tun, per Email. Mich als OpenSuse-Nutzer derart juristisch in Gefahr zu bringen, werde ich nicht zulassen. Wenn man z.B. keinen VLC in der Distro hat und Xine fast bis zur Funktionsunfähigkeit "verkrüppelt" - gerade wegen dieser glasklaren MPEG-LA-Patente - dann darf man so etwas niemals tun, auch nicht für Moonlight. Lizenziert es, so wie es sich gehört, oder lasst es ganz einfach sein. Wenn man sich die bisherige OpenSuse-Policy im Umgang mit proprietären und von aktuellen Patenten bedrohten freien Multimediacodecs ansieht, so ist dieses Vorgehen schlichtweg unverständlich.
IMHO ist das die nackte Panik. So einen Unsinn - nämlich ein Softwareprodukt von der Funktionsweise, der zu 100% fremdbestimmten Existenz und dem unbekannten juristischen Stand an tatsächlich für GNU/Linux bezahlten Patentlizenzen eines rein proprietären Treibers einer singulären Hardwarefirma abhängig zu machen und das unter einem freien Betriebssystem - habe ich schon lange nicht mehr gelesen.
Wenn man sich das nüchtern betrachtet, so ist das ohnehin eine Totgeburt. So wurde ja RealPlayer11 aus der OpenSuse-Distro verbannt, weil man Angst hat, dass man wegen des darin enthaltenen WMA- und WMV-Supports u.a. Lizenzärger mit Microsoft bekommen könnte. Und jetzt so was. Nein danke.
Für den patentbehafteten Silverlightkram, auf der mit Microsoft-Patenten zugepflasterten .NET-Implementierung Mono, wird eine Funktion einer aktuellen Grafikkarte des, für seine miserable Einstellung gegenüber freier Software bekannten, Herstellers Nvidia benötigt, die man nur mit dessen proprietären Treiber nutzen kann.
Ich kann meine Begeisterung kaum zurückhalten. :D
Man ich hab sogar richtig Lust an dem Projekt mitzuarbeiten und meine Freizeit dafür herzugeben. Wenn ich hier mitmache, helfe ich bestimmt ganz ganz vielen Leuten und bin dabei einen offenen Standard zu etablieren.
Wenn ich sowas lese, kann ich nur hoffen, dass Firefox 3.1 und Opera 10 bald fertig werden und mit ihrer Unterstützung für den Video-Tag und Theora bald eine Alternative zu diesen dämlichen und proprietären Plugins schaffen.
http://www.pro-linux.de/news/2008/13563.html
Soweit ich das sehe, verkündet Nvidia da, dass sie OpenCL ganz toll finden, damit grad rumspielen und das demnächst vielleicht irgendwann mal unterstützen werden.
Abgesehen davon löst OpenCL nicht die besagte Lizenzproblematik, denn man muss ja immer noch eigenen Code schreiben, der die patentieren Codecs implementiert.
Die Nvidia Karten können das doch offensichtlich nicht, also muss man es rein programmieren
Nur wo ist der Unterschied ?
Geht es um Verfahrenslizenzen oder um die reale Implementierung (Programmcode) des Verfahrens ?
Also brauch das Programm keinen decoder mehr, sondern nur noch eine schnittstelle zur API
VDPAU rockt übrigens jetzt schon obwohl es noch in der Test-Phase ist. Nachdem AMD es schon ewig nicht hinbekommt Video-Ausgabe über simples Xv ohne tearing hinzubekommen zieht Nvidia einfach dieses Ass aus dem Ärmel. Ich hatte mich lange genug mit einer AMD Karte rumgeschlagen und auf vernünftige Treiber für Video gucken gewartet. Jetzt eine billige Nvidia drin, alle Probleme gelöst. CPU-Auslastung mit VDPAU bei HD-Auflösungen: nahe Null.
Welche GPUs betrifft das überhaupt?
Und:
Seit wann bezahlt NVidia für meine ATI-Karte die Lizenzgebühren?
Falls nicht, ab in den "Trash" mit dieser Idee.
VDPAU ist eine offene API, Intel plant wohl schon Unterstützung, ob AMD mal aus dem Quark kommt ist eine andere Frage. Eine neue API war dringend nötig, da die bisherigen (XV & Co) für GPU-Decoding nutzlos sind.
Kann das mein heißgeliebter nv-Treiber?
was eine tolle Sache ist. Den einzigen Hersteller, der open source Treiber rundheraus ablehnt so zu unterstützen.
Aber von der mono-Bande kann man nichts anderes erwarten.
Was den nv Treiber angeht, der wird nie mehr können als 2D, mit noveau könntest du in Zukunft ein bisschen Glück haben, aber diesen Masochismus würde ich mir nicht antun, der Nvidia Treiber ist imho momentan der beste OpenGL Treiber für Linux.
Mit DRI2 und Gallium3D mit LLVM könnte einer der beiden freien ati treiber mal richtig gut werden.. leider fürchte ich, dass bis dahin die Hardware, für die das zutrifft völlig veraltet ist - oder es wird alle Hardware unterstützt, dafür aber nur mäßig. Eher könnte der fglrx aufhohlen, aber das glaube ich auch nicht, jetzt wo AMD das Entwicklungsteam zusammenstreicht.
Der Mangel an Entwicklern wird aber dadurch nicht besser, dass gleich zwei verschiedene Treiber für die selbe Hardware parallel entwickelt werden..
Dafür brauchts vielmehr eine anständige Compilerarchitektur. Da ist zwar mit der LLVM-Integration was in Aussicht, aber bis das auf dem Niveau der proprietären Treiber läuft, ist noch einiges mehr an Arbeit nötig.
Es gibt eine Xorg-Sponsorship.
Vielleicht hast Du ja irgendwann einmal einen sehr guten Job, dann denkst Du vielleicht einmal daran. :-)
Ich sehe diese Seite allerdings heute auch das erste Mal, weil ich erst vor ein paar Minuten überhaupt danach gesucht habe.
Was die eigentlichen Donations anbelangt, so verstehe ich aber leider nur "Bahnhof":
http://www.x.org/wiki/SponsorshipPage
Das sieht nicht so aus, als würde man kleine Spenden brauchen (?).
Hust. Ich verwende nvidia-Karten seit genau 2003. Wenn ich daran denke wie oft irgedwas nicht funktionierte was definitiv auf nvidia zurückzuführen war, wäre ich persönlich mehr als vorsichtig denen irgendwas positives zu unterstellen.
Zumindest unter Linux ist die Treiberqualität bestenfalls schwer-scheiße.
Leider brauche ich 3D-Beschleunigung aus beruflichen Gründen. Dennoch tut es weh zu sehen wie immer mehr Firlefanz plötzlich in GPU's berechnet werden soll die so transparent sind die Omas extra-dicker Thrombosestrumpf.
written under nv, cheers
Nur Anwender, die Moonlight direkt von Novell heruntergeladen haben, sollen von der Kooperation betroffen sein. Für andere Distributoren oder OEM-Hersteller stellt sich die Sache schwieriger dar. Die Nutzung der Codecs wird unklar und eine Patentklage der MPEG LA oder Microsoft durchaus wahrscheinlich.
noch mehr Verwirrung was man jetzt darf oder nicht (ist opensuse in dem fall novell?)
Ich glaub da is mir lieber etwas is MS only als so eine Lösung
Wenn sie es in den nächsten 14 Tagen nicht tun, werde ich es tun, per Email.
Mich als OpenSuse-Nutzer derart juristisch in Gefahr zu bringen, werde ich nicht zulassen.
Wenn man z.B. keinen VLC in der Distro hat und Xine fast bis zur Funktionsunfähigkeit "verkrüppelt" - gerade wegen dieser glasklaren MPEG-LA-Patente - dann darf man so etwas niemals tun, auch nicht für Moonlight.
Lizenziert es, so wie es sich gehört, oder lasst es ganz einfach sein.
Wenn man sich die bisherige OpenSuse-Policy im Umgang mit proprietären und von aktuellen Patenten bedrohten freien Multimediacodecs ansieht, so ist dieses Vorgehen schlichtweg unverständlich.
So einen Unsinn - nämlich ein Softwareprodukt von der Funktionsweise, der zu 100% fremdbestimmten Existenz und dem unbekannten juristischen Stand an tatsächlich für GNU/Linux bezahlten Patentlizenzen eines rein proprietären Treibers einer singulären Hardwarefirma abhängig zu machen und das unter einem freien Betriebssystem - habe ich schon lange nicht mehr gelesen.
So wurde ja RealPlayer11 aus der OpenSuse-Distro verbannt, weil man Angst hat, dass man wegen des darin enthaltenen WMA- und WMV-Supports u.a. Lizenzärger mit Microsoft bekommen könnte.
Und jetzt so was.
Nein danke.
Ich kann meine Begeisterung kaum zurückhalten. :D
Man ich hab sogar richtig Lust an dem Projekt mitzuarbeiten und meine Freizeit dafür herzugeben. Wenn ich hier mitmache, helfe ich bestimmt ganz ganz vielen Leuten und bin dabei einen offenen Standard zu etablieren.
Ist ja echt nicht mehr zum Aushalten.
Tom-Tom und Microsoft haben ein Patentabkommen geschlossen:
http://www.golem.de/0903/66218.html