News [Update: HSA] Open Source UVD2-Unterstützung mit VDPAU(!) von AMD freigegeben!

User-News

Von nazgul99

Hinweis: Diese "User-News" wurde nicht von der Planet 3DNow! Redaktion veröffentlicht, sondern vom oben genannten Leser, der persönlich für den hier veröffentlichten Inhalt haftet.
Wie Phoronix berichtet, hat AMD OpenSource-Unterstützung für UVD2 (ab R700) für freien und offenen Radeon-Treiber unter Linux veröffentlicht! Für nicht eingeweihte: Als Alternative gibt es auch den proprietären (binär, kein offener Quellcode) FGLRX- bzw. Catalyst-Treiber, der UVD schon länger unterstützt, aber nur mittels XvBa (s.u.). FGLRX ist zwar schneller und mit OpenGL 4.2 ausgestattet, aber weniger stabil als der freie Treiber, der bisher maximal OpenGL 3.0 (und ein paar höhere features) unterstützt. Obendrein werden neuere Linux-spezifische Features (z.B. Grafikmodus-Umschaltung durch den Kernel gleich beim Booten -> schneller, konsistenteres Boot-"Erlebnis"), die aktuellsten X-Server (der die grafische Oberfläche anzeigt) und manchmal auch neueste Kernel-Versionen zuerst von den freien Treibern unterstützt, gleiches dürfte für modernen X-Ersatz wie Wayland gelten.

Eine der erfreulichsten Nachrichten ist dabei, dass die Software-Schnittstelle VDPAU gewählt wurde - diese ist ursprünglich von Nvidia erdacht worden und weist die breiteste Unterstützung in Linux-Programmen auf. AMD hatte hier einst den Konkurrenz-Standard XvBa eingeführt, welcher aber von den wenigsten software-Titeln unterstützt wird. Intel liegt mit VA-API im Mittelfeld.

Es geht hierbei auf jeden Fall um Decodierungs-Fähigkeiten. Ob auch bereits Encodierung (ab UVD3?) unterstützt wird, ist aus der Meldung nicht erkennbar. Evtl. steht mehr im zugehörigen Forums-Thread (hab ich noch nicht lesen können).

Einer der größten Nachteile des freien Radeon-Treibers ist die noch mangelnde 3D-Unterstützung der aktuellsten Radeon-Hardware, namentlich Southern Islands aka GCN. Jüngste Ankündigungen auf Phoronix lassen aber vermuten, dass sich auch dies in Bälde ändern könnte. Ich vermute/hoffe, dass der freie GCN-Sub-Treiber "RadeonSI" spätestens zum Erscheinen von Kaveri auf dem gleichen Stand ist wie seine Vorgänger.

Somit scheint sich abzuzeichnen, dass zukünftig alle Compute-Funktionen der APUs auch ohne proprietäre Treiber genutzt werden können - für HSA ist das ja ohnehin angekündigt (sofern ich dies richtig verstanden habe).

Neuheiten gibt es auch zu aktualisierter Unterstützung von Power-Saving-Untertützung für AMD-CPUs unter Linux - hier wurde ja nach Schließung von AMDs OpenSource-Schmiede in Dresden Stillstand befürchtet.

Eine Übersicht über die vorhandenen und geplanten Features der freien AMD-Radeon-Treiber findet sich im X-Org Wiki. Momentan ist die Seite auf dem Stand vom 25. Februar (Datum steht ganz unten), seitdem hat sich (endlich wieder) einiges getan.

Für den Endbenutzer, der keine eigenen Kernel- und Grafikpakete selbst kompilieren mag, sind die neuesten Features der freien Grafiktreiber normaler Weise erst nutzbar, wenn eine Distributions-Version mit den aktuellen Treibern und passendem Kernel herauskommt. Z.B. bei Ubuntu dürfte das erst mit der Herbst-Version 13.10 der Fall sein.

So oder so, dies ist ein schöner Tag! *em_jubel*

Edit:
OpenCL-Unterstützung in LLVM (open Source). Problem mit dem freien UVD-Treiber: Ein Teil des Ganzen ist in einer vorkompilierten Firmware verpackt, also nicht komplett frei. Liegt vermutlich an der DRM-Verbundelung, die von Anfang an DER Hinderngsgrund für den freien UVD-Treiber war.

Noch ein Vorteil des freien Radeon-Treibers: Es wird auch weiterhin "veraltete" Hardware unterstützt, siehe dazu die Feature-Liste im X-Org Wiki (Link weiter oben)

Edit 2:
Ein paar weitere Infos (Zusammenfassung aus Foren-Posts) gibt's hier! PowerManagement-Verbesserungen sollten eigentlich vor UVD veröffentlicht werden, hat aber doch noch nicht geklappt. Bridgman und Christian König sind beide AMD-Angestellte und (u.a.?) im Bereich des freien Radeon-Treibers tätig. Die X.org-Wiki-Seite zum Radeon-Treiber wurde inzwischen auch aktualisiert. Stabile Release-Treiber mit UVD-Support (insbesondere Gallium3D/MESA, das ist der gemeinsame 3D-Code für alle freien Grafiktreiber) sind erst zum Jahresende zu erwarten, einige Distributionen integrieren aber gern mal Vorversionen. Für Ubuntu gibt's auch das xorg-edgers PPA (inoffizielle externe Pakete), welches stets "bleeding edge" (daher wohl "edgers"), also taufrische X-, und zugehörige Treiber-Pakete liefert. Natürlich sind diese nicht ausgetestet, also möglicher Weise instabil und geeignet, ein installiertes System zu zerschießen.

Edit 3:
Das hab ich jetzt etwas spät bemerkt, aber einen Tag nach meiner letzten Änderung gab es noch eine zum Thema passende Meldung: Compute-Support im RadeonSI-Treiber. RadeonSI ist der Teil im freien Radeon-Treiber, der sich um GCN kümmert. Die Implementierung ist der Meldung zufolge noch nicht "zu gut", sprich: "weit entfernt von der Qualität" der nicht-offenen Treiber AMDs und Nvidia. Ob sich dies Feature-Vollständigkeit, Stabilität oder Performanz bezieht, ist der Meldung nicht zu entnehmen. Für den R600/R700-Treiber gab es bereits OpenCL-Unterstützung, die im X.Org-Wiki noch als "WIP" aka "In Arbeit" bezeichnet wird.

Damit ist ein weiterer Schritt in Richtung volle OpenSource-Unterstützung aller Komponenten (nunja bis auf die Digitale-Rechte-Mangel) in Kaveri gemacht.
 
Zuletzt bearbeitet:
Falls jemand das Thema abonniert haben sollte (kommt ja erst eine Mailmeldung, wenn man einen Post anhängt, nicht ändert), merke ich hier mal an, dass ich im Startpost einen Nachtrag zu HSA/Compute/OpenCL gemacht habe.

Freut mich übrigens zu lesen, dass so viele P3D-Mitglieder an OpenSource-Themen interessiert zu sein scheinen!
 
nazgul99 schrieb:
Es geht hierbei auf jeden Fall um Decodierungs-Fähigkeiten. Ob auch bereits Encodierung (ab UVD3?) unterstützt wird, ist aus der Meldung nicht erkennbar. Evtl. steht mehr im zugehörigen Forums-Thread (hab ich noch nicht lesen können).
Zum Vergrößern anklicken....
Der Patch/Firmware unterstützt alle aktuellen GPUs, bis zu Oland, also die kommenden HD8000er. Schon Cayman war UVD3, also ist die Unterstützung vorhanden.

Problem mit dem freien UVD-Treiber: Ein Teil des Ganzen ist in einer vorkompilierten Firmware verpackt, also nicht komplett frei. Liegt vermutlich an der DRM-Verbundelung, die von Anfang an DER Hinderngsgrund für den freien UVD-Treiber war.
Zum Vergrößern anklicken....
Dass der Treiber auf Firmware-BLOBs angewiesen ist, ist aber schon sehr lang so und nicht auf UVD beschränkt. Und das wird auch für das PowerManagement so werden, da sich das im Treiber nur unzureichend realisieren lässt.

Neuheiten gibt es auch zu aktualisierter Unterstützung von Power-Saving-Untertützung für AMD-CPUs unter Linux - hier wurde ja nach Schließung von AMDs OpenSource-Schmiede in Dresden Stillstand befürchtet.
Zum Vergrößern anklicken....
AMD hatte ja angekündigt, dass sie weiter OpenSource unterstützen wollen. Nur der Standort Dresden wurde leider geopfert. Davon abgesehen sind die Linux-Maintainer immer noch die ehemaligen AMD-Angestellten.
 
nazgul99 schrieb:
Es geht hierbei auf jeden Fall um Decodierungs-Fähigkeiten. Ob auch bereits Encodierung (ab UVD3?) unterstützt wird, ist aus der Meldung nicht erkennbar. Evtl. steht mehr im zugehörigen Forums-Thread (hab ich noch nicht lesen können).
Zum Vergrößern anklicken....
UVD kann nicht Enkodieren. Alle UVD-Versionen - also auch UVD3 - können nur Videocodecs dekodieren. Wo kommt dieser oftmals geäußerte Irrglaube her, das UVD (Unified Video Decoder) auch enkodieren könnte?

Das macht die VCE-Einheit.
 
Dr@ schrieb:
UVD kann nicht Enkodieren. Alle UVD-Versionen - also auch UVD3 - können nur Videocodecs dekodieren. Wo kommt dieser oftmals geäußerte Irrglaube her, das UVD (Unified Video Decoder) auch enkodieren könnte?

Das macht die VCE-Einheit.
Zum Vergrößern anklicken....
Äh ja, und das würde ich der Qualität wegen auch weiterhin der Software überlassen.
 
Danke!

VCE: Gut, der "kleine Unterschied" lag bei mir jetzt nicht auf dem Tablett. Ich enkodere auch lieber in Software, aber ihr wisst ja .. Verkaufsargumente ...
 
Noch ein Bröckchen: Tom Stellard von AMD hat den Bitcoin-Miner "bfgminer" mittels OpenSource-Radeon OpenCL zum Laufen gebracht. Er benutzt dafür noch eigens angepasste Mesa, LLVM, und libclc OpenCL Library und es läuft weniger schnell als mit den Binär-Treibern, aber es läuft. Allerdings erst auf HD5/6000, nicht auf HSA.
 
nazgul99 schrieb:
Noch ein Bröckchen: Tom Stellard von AMD hat den Bitcoin-Miner "bfgminer" mittels OpenSource-Radeon OpenCL zum Laufen gebracht. Er benutzt dafür noch eigens angepasste Mesa, LLVM, und libclc OpenCL Library und es läuft weniger schnell als mit den Binär-Treibern, aber es läuft. Allerdings erst auf HD5/6000, nicht auf HSA.
Zum Vergrößern anklicken....
Jetzt hilf mir mal einer auf die Sprünge, für was HSA hier steht.
 
PuckPoltergeist schrieb:
Jetzt hilf mir mal einer auf die Sprünge, für was HSA hier steht.
Zum Vergrößern anklicken....
Das war der kürzeste Begriff für das Thema, ich wollte den Titel nicht zu lang machen. Ich erkenne an, dass das nicht ganz korrekt ist. Ich sehe Shader-Computing im HSA-Kontext, OpenCL gehört natürlich nicht eigentlich zu HSA (soweit ich weiß). Das wird mir so aber erst jetzt bewusst, wo ich dies schreibe. Ich ändere das jetzt aber nicht nochmal, da sonst Leute meinen könnten, ich hätte noch was neues dazu geschrieben und extra deswegen nochmal meinen Beitrag aufrufen.
.
EDIT :
.
Wer genauer sagen kann, in wieweit OpenCL (auch oder eben nicht) etwas mit HSA zu tun hat, nur her mit der Info! Und auch Infos, ob und wie weit das eigentliche HSA in freier Software mit freien Treibern unterstützt wird / werden sollen, sind sehr willkommen.

Zum ursprünglichen Thema, dem UVD-Code:
Der UVD-Code ist nun inn der 3D-Bibliothek Mesa gelandet, im Entwickler-Zweig natürlich. Wann dieser in einem Release beim Enduser auftaucht, ist nicht festgelegt, im ersten Post war von Ende des Jahres zu lesen. Der zugehörige Kernel-Code soll, ich zitiere: "there's also kernel Radeon DRM changes needed that won't be merged until the Linux 3.10 kernel", ich interpretier das mal als "nicht vor Kernel 3.10" im Kernel landen. Etwas knifflig formuliert, könnte es auch "nicht bis Kernel 3.10" (so klingt es wörtlich, ich interpretier es aber anders), also erst kernel 3.11 heißen.

DRM steht hier übrigens für "Direct Rendering Manager", nicht die Rechte-Entzugsmechanismen gegen den Benutzer mit dem gleichen Kürzel.

Und das X.Org-Wiki ist jetzt auch im Bezug auf RadeonSI Mesa3D-Featuers aktualisiert worden. OpenCL ist dort weiterhin als "WIP", in Arbeit, markiert.
 
Ah gut. Also da steht auch OpenCL im Kontext (unter der Überschrift und zwischen den spezifischen HSA-Punkten) von HSA. Lag ich hoffentlich nicht gänzlich falsch.

Ähm, ach ja: Danke :-)
 
Zuletzt bearbeitet:
nazgul99 schrieb:
Ah gut. Also da steht auch OpenCL im Kontext (unter der Überschrift und zwischen den spezifischen HSA-Punkten) von HSA. Lag ich hoffentlich nicht gänzlich falsch.
Zum Vergrößern anklicken....
OpenCL ist eine Programmiersprache und HSA in erster Linie eine optimierte Hardwarespezifikation für heterogene System (beliebige Kombination von x86-, GPU-, ARM-Kerne, irgendwelche speziellen Fixed-Function-Blöcke, ...), zu der ein spezielles Speicher- und Programmiermodell gehören.

Durch HSA sollen sich effizientere GPU-beschleunigte (nicht nur!) Programme mit Hilfe von OpenCL und DirectCompute schreiben lassen. Zudem lassen sich darüber alle weiteren Hardwareblöcke wie beispielsweise die UVD- und VCE-Einheit ansprechen.

Außerdem sollten HSA-Programme nicht nur auf x86-System laufen sondern irgendwann mal auch auf den Handy-Chips und Serverprozessoren der beteiligten ARM-Hersteller.
 
Ja ok. OpenCL ist natürlich nicht an sich HSA sondern eher ein Zwischenschritt - aus AMDs Sicht und der der HSA-Foundation-Mitglieder - so sehe ich das jedenfalls. Im Prinzip, wieder meine Sichtweise, soll HSA so etwas wie OpenCL überflüssig machen, da HSA-befähigte Programme/Binaries/Kompilate/Meta-Binaries prinzipiell aus jeder beliebigen (für die es die entsprechenden Compiler gibt) Programmiersprache erstellt werden könnten.

Ungefähr korrekt?

Ich vermute mal, dass HSA mittels Compiler für die jeweils gewählte Sprache tatsächlich so etwas wie Zwischen-Binaries erstellt, welche dann von Runtime-Compilern für die jeweils vorhandenen Ziel-Architekturen (AMD64/ARM(/64)/GCN/wasweißich) und Schnittstellen (Firmware/Betriebssystem/Treiber) aufbereitet und mittels eines Schedulers/Balancers anhand der zur Verfügung stehdenden / für dieses Prog bereit gestellten (je nach Priorisierung durch BS und/oder HyperVisor) Ressourcen Threads möglichst optimal verteilt und ausgeführt werden.

No?

Argh, der Satz ist zu lang, ich hoffe, er fuktioniert ;D

Bin gespannt auf die Resultate, wozu ich auch die Werkzeuge und eben (Thread-Thema 2) Treiber zähle. Der ganze Mechanismus scheint mir reichlich komplex, ich hoffe es gelingt - inklusive der benötigten Effizienz.
 
Zitiere aus dem link:
AMD is starting this process by delivering HSA optimized programming tools for today’s most widely available heterogeneous languages: OpenCL™ and C++ AMP. Going forward, AMD along with the HSAF members will expand the set of developer tools to encompass many other languages and libraries across multiple software domains and segments.
Zum Vergrößern anklicken....
Ok, danke!

"Many other languages" könnte auf diesen Zweck spezialisierte Sprachen wie OpenCL (und C++ AMP, auf diesen Begriff stoße ich jetzt vermutlich erst zum 2. Mal) irgendwann überflüssig machen - oder es tritt der genau umgekehrte Effekt ein. Sofern HSA oder etwas ähnliches sich durchsetzt. Und abhängig von der trägen Masse der Entwickler und Firmen.

Na gut, reine Spekulation oder besser: Spökenkiekerei meinerseits ;D
 
Torsten Leemhuis (c't) hat etwas zum Thema geschrieben - und ergänzt: Der Kernel-Patch ist in der Tat für 3.10 vorgesehen. Und er erwartet, dass Linux-Distris die MESA-Neuerungen bald in ihre Entwicklung mit aufnehmen werden. Wann das zu fertigen Distris mit diesen Patches führt, ist damit noch nicht gesagt. Aber es gibt eine Lizenz-Einschränkung, die bei Distributionen, die es mit den Lizenzen sehr genau nehmen, zum Ausschluss (vermutlich des Binary-Blobs) führen könnten:
Torsten Leemhuis schrieb:
Mit der UVD-Unterstützung in Mesa stieß nämlich eine Readme-Datei zu Mesa 3D, die betont, der Code würde Techniken anderer Parteien implementiert, aber keine Lizenz für diese enthalten; als Beispiel sind H.264, MPEG-2, MPEG-4, AVC und VC-1 genannt. Zudem sei die Funktion zum Encoden von MPEG-2 nur für private Zwecke ("Personal Use") gestattet.
Zum Vergrößern anklicken....
Sofern bei den "strengen" Distris (ich vermute z.B. Debian) nur der Binärteil ausgeschlossen wird, dürfte dieser trotzdem relativ leicht - als Firmware-Datei - nachzuinstallieren sein.

Immerhin ist hier zu erkennen, dass offenbar auch Encodierungsfunktionen enthalten sind.
 
Zuletzt bearbeitet:
Dr@ schrieb:
Zum Thema HSA hatte ich hier das wichtigste geschrieben.

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1339584790
Zum Vergrößern anklicken....
Danke, irgendwie so was hatte ich auch noch im Hinterkopf. Hat also erst mal nicht wirklich was mit der UVD- oder OpenCL-Implementierung zu tun.

Und zum Thema Encoding-Funktion, die Passage im README ist folgende:
For MPEG-2 Encoding Products ANY USE OF THIS PRODUCT IN ANY MANNER OTHER
THAN PERSONAL USE THAT COMPLIES WITH THE MPEG-2 STANDARD FOR ENCODING VIDEO
INFORMATION FOR PACKAGED MEDIA IS EXPRESSLY PROHIBITED WITHOUT A LICENSE
UNDER APPLICABLE PATENTS IN THE MPEG-2 PATENT PORTFOLIO,
Zum Vergrößern anklicken....
Da steht erst mal gar nichts, dass mit dieser Implementierung auch encoded werden kann.

PS: Und soweit sich da nichts geändert hat, hat auch VDPAU keine Funktionen zum encoden. Es ist ja auch ein Akronym für Video Decode and Presentation API for Unix. Da fehlt ein E für Encode im Namen. ;)
 
Zuletzt bearbeitet:
"MPEG-2 standard for encoding video", nur eine Lang-Bezeichnung für "MPEG-2". Da ist Herr Leemhuis offenbar auf die Formulierung reingefallen. Danke für die Klärung!
 
PuckPoltergeist schrieb:
Und zum Thema Encoding-Funktion, die Passage im README ist folgende:

Da steht erst mal gar nichts, dass mit dieser Implementierung auch encoded werden kann.
Zum Vergrößern anklicken....

Das ist doch den "Patent- Pools" egal. Die denken doch auch, dass die 2+2=4 patentiert hätten und aus großem Mitgefühl verklagen die niemanden deswegen ;)
 
Wenn jetzt nichts Unvorhergesehenes mehr passiert, landet der UVD-Support im 3.10er Kernel. Dave Airlie hat den Code in seinen drm-next tree übernommen.
 
Moin, es gibt eine Riesen-Patchwelle für den Radeon-Treiber (in erster Linie für den Direct Rendering Manager im Kernel-Teil, vermutlich auch für den X11/Gallium-Radeon-Treiber selbst): 165 Patches inklusiver dynamischem Reclocking, Dynamic Power Management, ASPM und Unterstützng für CIK aka Sea Islands für Kaveri, Kabini und Bonaire! Ähm, was war gleich Bonaire?

Auf manches dieser Features dürften viele sehnsüchtig gewartet haben, meine Wenigkeit inklusive. Kann ich meinen MC101 dann doch wahrscheinlich endlich auf den freien Treiber umstellen, möglicher Weise schon mit Ubuntu 13.10 :)

Das Ganze ausführlicher bei Phoronix!
 
Zuletzt bearbeitet:
Ah danke, diskrete GPU. Das ist nicht meni Feld :)
 

Ähnliche Themen

E555user
News Linux Desktop für Radeon von AMD
Antworten
0
Aufrufe
297
E555user
E555user
eratte
AMD Ryzen AI 9 HX375/370/365/350 Notebook & Mini PC (ZEN5 12/10 Kerne, RDNA 3,5) Review und Diskussionsthread - Links in Post 1
4 5 6
Antworten
141
Aufrufe
8K
eratte
eratte
E555user
News AMD FSR4 & FidelityFX Adaption
Antworten
2
Aufrufe
516
E555user
E555user
pipin
News Neue AMD Radeon Software Adrenalin mit Noise Suppression
Antworten
23
Aufrufe
2K
sompe
S
P3D-Bot
News SETI.Germany : Asteroids@home: OpenCL-Anwendung für AMD-Grafikkarten und Veröffentlichung neuer Rotationsperioden
Antworten
0
Aufrufe
583
P3D-Bot
P3D-Bot
Zurück
Oben Unten