News AMD: PowerPlay für AMDGPU-Treiber unter Linux kommt im März

[Shririnovski]

Spitze, das bringt AMD voran, das bringt Gaming unter Linux voran, freut mich

 

[var const]

AMDGPU war urspruenglich fuer 4.2 geplannt. Es wurde langsam Zeit

AMDGPU kam ja auch bereits mit Kernel 4.2. Nur war da noch kein Support für Powerplay drin, denn das war erst für 4.4 geplant, was nun gerade so verpasst wurde.

 

[batetogoiko]

AMDGPU kam ja auch bereits mit Kernel 4.2. Nur war da noch kein Support für Powerplay drin, denn das war erst für 4.4 geplant, was nun gerade so verpasst wurde.

Naja, wenn du es sogar als "initial Support" drehen willst, funktional war es im 4.2 nicht: http://www.phoronix.com/scan.php?page=article&item=amd-tonga-linux42&num=3
Danach lief es zumindest mit 4.3 besser, war aber mit unter 10fps bei meiner 285 (Tonga) nich gerade toll. Von deren freature plaene mit dem "neuen tollen sockel driver model" reden die seit einanhalb jahre. Langsam wir Zeit zu liefern.

 

[eruanno]

Nochmal: "amdgpu" hat nichts mit 3D-Beschleunigung zu tun und mal davon abgesehen gehört letztere mit Sicherheit auch nicht zum "initial support".
Ja klar, seit 1,5 Jahren... so lange ist deine Karte ja noch nichtmal auf dem Markt. Damals wurden vielleicht erstmals Gerüchte laut. Gegen Ende letzten Jahres hat AMD bekanntgegeben, dass man einen gemeinsamen Unterbau, also den Kerneltreiber, für beide Stacks will. Man hat sich dann verständlicherweise bei amdgpu auch erstmal auf Carrizo fokussiert. Dass man den userspace Kram (also deine 3D Beschleunigung, Videofunktionen, Computing, etc. -> catalyst) für Privatanwender auch fallen lässt, und stattdessen mesa/radeonsi und gallium unterstützt, wurde auf der xdc bekanntgeben und die war Ende September.
Dass der Umbau nicht von heute auf Morgen geht muss dir doch damals beim Kauf klar gewesen sein. Das zimmert man auch nicht von heute auf morgen zusammen. Die sollen sich ruhig Zeit lassen, wenn sie es denn diesmal richtig machen (und es sieht bisher gut aus)

phoronix hat jetzt übrigens die Ergebnisse oben, allerdings nur die langweiligen (ohne vs mit dem Patchset): http://www.phoronix.com/scan.php?page=article&item=amdgpu-powerplay-test&num=2
Die "richtigen" Vergleiche mit anderen Karten sollen aber im Laufe des Wochenendes noch folgen

 

[pipip]

Maxwell ist massiv effizienter als so eine alte AMD GPU.

Apple nützt aber bisher als einziger einen Tonga Chip und das ist auch der aktuell jener Chip, der für die schnellste Notebook-Lösung eingesetzt wird. Ich glaube nicht, dass ein halbierter Tonga als pitcairn ersatz soviel schlechtere Effizienz als GM107 gehabt hätte, speziell weil pitcairn als R9 370 bzw R9 270X keine wesentliche schlechtere Effizienz als die 950 GTX hat.

 

[Stebs]

Dass man den userspace Kram (also deine 3D Beschleunigung, Videofunktionen, Computing, etc. -> catalyst) für Privatanwender auch fallen lässt, und stattdessen mesa/radeonsi und gallium unterstützt, wurde auf der xdc bekanntgeben und die war Ende September.

Das wäre mit neu, bis jetzt dachte ich, AMD setzt in Zukunft auf den AMDGPU Teil im Kernel und einem neuen (umgebauten) Teil im Userspace, als Alternative zu mesa/radeosi.
Gibt es in Zukunft für neue AMD-Karten wirklich nur Open-Source Treiber? (für "normale" Endanwender)
Oder ist der neue Userspace-Treiber von AMD nur noch nicht verfügbar?...

 

[Zehkul]

Ja und nein. Das einzige, was AMD im neuen gemischten Stack geschlossen lassen will, ist der OpenGL Teil, der umgebaut wird, dass er auf dem freien Stack unter AMDGPU funktioniert. Und dieser Umbau ist noch nicht verfügbar, ja. Das mag auf den ersten Blick ziemlich signifikant erscheinen und ist es derzeit auch noch, aber mit Vulkan wird die Bedeutung von OpenGL eh absinken, und der Vulkan Treiber wird open source sein.

Obendrein hat AMD schon bevor sich irgendwas um Vulkan herum getan hat viel an Mesa gearbeitet, andere Firmen (auch große Brocken wie Intel) arbeiten ebenfalls daran, auf lange Zeit gesehen hat AMDs geschlossener OpenGL Treiber überhaupt keine Chance, da mitzuhalten. Es wird also zwangsläufig alles open source für AMD unter Linux, die Frage ist nur, wie lange das dauert.

 

[Stebs]

Und dieser Umbau ist noch nicht verfügbar, ja. Das mag auf den ersten Blick ziemlich signifikant erscheinen und ist es derzeit auch noch, aber mit Vulkan wird die Bedeutung von OpenGL eh absinken, und der Vulkan Treiber wird open source sein.

OpenGL wir aber nie komplett durch Vulkan ersetzt, so sehr ich mir das auch wünschen würde.
Andererseits sollte man mit seinen Wünschen vorsichtig sein. Der Vulkan-Treiber wird ja klein und einfach sein (immer im Vergleich zu OpenGL-Treibern), da habe ich keine Bedenken dass ein Open-Source Treiber nicht passen wird.
Aber die Optimierungen müssen bei Vulkan ja von der Applikation/Game gemacht werden, und wer mitbekommen hat was da derzeit schon mit OpenGL verbrochen wird, kann sich ja ausmalen was passiert, wenn wirklich jede Applikation/Game auf Vulkan portiert würde...

IMHO wird alles, was keine "fertige" 3DEngine benutzt, oder gar mit eigener 3DEngine daherkommt (im Endeffekt also jedes Quäntchen Performance brauch), noch lange bei OpenGL bleiben. Würde man modernes und korrektes OpenGL nutzen, wäre das ja auch gar nicht so schlecht.
Und die bestehenden Programme die das Compatibility-Profil brauchen sollte man auch nicht vergessen, die werden die nicht-freien Treiber brauchen.

 

[Zehkul]

Und die bestehenden Programme die das Compatibility-Profil brauchen sollte man auch nicht vergessen, die werden die nicht-freien Treiber brauchen.

Gibt es nahezu keine. Das einzige Beispiel, das ich kenne, ist (war!) Natural Selection 2, das funktioniert mittlerweile auch ohne legacy context.

Intel ist mittlerweile etwas, für das Spiele, die nicht gerade die extremsten AAA Titel sind, einfach Support haben müssen, und Intel ist komplett open source und hinter Mesa.

IMHO wird alles, was keine "fertige" 3DEngine benutzt, oder gar mit eigener 3DEngine daherkommt (im Endeffekt also jedes Quäntchen Performance brauch), noch lange bei OpenGL bleiben.

Da unterschätzt du denke ich, wie viele „fertige 3D Engines“ es gibt. Ja, Indies, die ihre eigene Engine zusammenhacken, also Spiele wie Banished, werden bei OpenGL bleiben(*), aber dort ist Performance auch ziemlich latte. Darüber hinaus nutzt jeder irgendetwas Größeres, und dabei rede ich nicht nur von großen Engines wie Unreal, sondern auch von den unzähligen In House Engines. Die Engine wird oft genutzt, und ein Vulkan/DX12 Renderbackend rentiert sich auch bei kleineren auf Dauer einfach. Das gilt umso mehr für Porter, die deutlich mehr Titel ausspucken, als irgendein Entwickler je könnte. Ein Porter wie Aspyr oder Feral schreibt nicht alles von Grund auf neu für jedes Spiel, so wäre das unbezahlbar, die haben ihre eigenen Tools, die mit jedem weiteren Spiel etwas verbessert werden und den nächsten Port etwas erleichtern. Die stecken ihr proprietäres Rendering doodoo in Unmengen von Spielen, so sehr unterscheidet sich das gar nicht von dem, was Virtual Programming mit eON oder CodeWeavers mit Winelib macht – oder Valve mit togl gemacht hat. Welches sie übrigens auch leicht direkt zu Release als ToVulkan raushauen könnten. Gar nicht mal so unwahrscheinlich, dass das kommt.

OpenGL 3.3 wird es noch lange geben, ja. Darüber hinaus? Fraglich. Das gibt es heute auch schon kaum, die wenigen, die tatsächlich GL4+ Funktionen nutzen, sind weit vorn am technologischen Fortschritt und werden auch schnell zu Vulkan springen, der Rest ist zufrieden mit 3.3 oder noch älteren Versionen, welche schon heute perfekt auf Mesa laufen. Talos Principle nutzt OpenGL 2.1, bei solchen Entwicklern ist es natürlich unwahrscheinlich, dass sie ihren trauten Hafen bald verlassen. Ist aber wie gesagt auch nicht nötig. Vor allem für zukünftige Karten nicht, die stark genug sind, dass Spiele wie Talos Principle so oder so mit 60fps laufen.


* Oder auch gerade nicht – eine eigene Engine für solche Projekte zu kreieren ist heutzutage an sich schon Zeitverschwendung und finanziell nicht wirklich sinnvoll (wenn ein Spiel wie Cities Skylines Unity nutzt, kann ein Banished das auch), geschieht also meist eher deshalb, weil der Dev schlicht Lust drauf hat. Für Entwickler, denen sowas Spaß macht, ist Vulkan höchst interessant. Mehr Programmieren, weniger mit kaputten Treibern rumärgern.

 

[Stebs]

Gibt es nahezu keine. Das einzige Beispiel, das ich kenne, ist (war!) Natural Selection 2, das funktioniert mittlerweile auch ohne legacy context.

Ich schrieb ja auch extra:

Und die bestehenden Programme die das Compatibility-Profil brauchen

OpenGL ist mitnichten nur für Spiele da, ohne z.B. professionelle OpenGL Programme wären die proprietären Linux Treiber heutzutage wohl noch viel rudimentärer. Nur weil nicht jeder sowas täglich nutzt, heißt das aber nicht, dass es nicht auch in Zukunft funktionieren muss.

Intel ist mittlerweile etwas, für das Spiele, die nicht gerade die extremsten AAA Titel sind, einfach Support haben müssen, und Intel ist komplett open source und hinter Mesa.

Das brauchst du mir wirklich nicht erzählen, ich sitze täglich an einem Ivybridge mit Mesa. Als "normaler" Nutzer sollte man aber auch oft übersehene OpenGL-nutzende Programme nicht vergessen. Von Media-Playern, Window-Manager/Compositor bis Browser.
Es mag da Ausnahmen geben, die tatsächlich zügig nach Vulkan wechseln, alle werden IMHO aber nicht schnell nach Vulkan wechseln können.
Die Firefox-Nightlys können z.B. erst seit ca 2 Wochen was mit dem Mesa OpenGL Core-Profil anfangen (für WebGL 2). Beim Chrome(ium) siehts afaik nicht viel anders aus. Vulkan würde ich da nicht so schnell erwarten.

Da unterschätzt du denke ich, wie viele „fertige 3D Engines“ es gibt.

Eigentlich nicht, aber Tatsache ist, dass z.B. Unity3D unter Linux sebst mit der aktuellsten Version standardmässig max. OpenGL 2.1 nutzt (sich allerdings bei Verfügbarkeit auch "bessere" Extensions dazuholt.)
Das neue modernisierte und zusammengefasste OpenGL-Backend ist unter Linux noch experimentell. Vulkan ist angedacht, aber ohne konkreten Termin.
Porter wie Aspyr und Feral werden zwar langsam besser und nutzen immer mehr moderneres OpenGL, aber selbst die machen angeblich teilweise noch hahnebüchene OpenGL-Fehler (aufgeschnappt in Foren von Leuten, die wissen wie man OpenGL debuggt, ist also meinetwegen Hörensagen).
Und die Leute oben sind sind ja noch fast die aktivsten, was das angeht.
Ich hoffe natürlich auch, dass Feral, Aspyr, Unity, Unreal, Crytek, Valve und Konsorten Vulkan schnell richtig hinkriegen und die Zukunft rosig aussieht (immerhin sollte auch DX12->Vulkan viel einfacher sein als DX11 -> OpenGL).
Aber ich glaube einfach nicht, dass OpenGL mittelfristig schnell unwichtig wird und proprietäre Treiber überhaupt keine Rolle spielen werden.
Schön wärs, aber ich glaubs nun mal nicht.
Andererseits, mit Vulkan (und auch den Fortschritten bei den Open-Source Treibern) sieht die Zukunft eh schon rosig aus, egal ob OpenGL noch lange Zeit daneben koexistiert.

OpenGL 3.3 wird es noch lange geben, ja. Darüber hinaus? Fraglich. Das gibt es heute auch schon kaum, die wenigen, die tatsächlich GL4+ Funktionen nutzen, sind weit vorn am technologischen Fortschritt und werden auch schnell zu Vulkan springen

Ich glaube dass DX11 Spiele auch weiterhin nach OpenGL4+ portiert werden (so wie Feral das zur Zeit macht) und dann nur DX12 Spiele nach Vulkan. Alles andere wären zu tiefgreifende Eingriffe in die originale Engine.
Jedenfalls ist der momentan fehlende proprietäre AMD-Treiber für die neuesten GPUs ein echtes Problem für besagte moderne Spiele, die von Feral portiert werden und wurden.

 

[eruanno]

Definitiv wird nicht alles auf Vulkan portiert, schon gar nicht in kürzester Zeit. Vulkan ist ja auch nicht als Nachfolger von OpenGL konzipiert, sondern eher eine Alternative. Implementierungen werden komplizierter sein, als noch mit OpenGL, man darf weniger Fehler machen und muss sich selbt um mehr kümmern. Dass der Treiber noch Validierung, Fehlerbehandlung etc. übernimmt, fällt mit Vulkan komplett weg.

Das wäre mit neu, bis jetzt dachte ich, AMD setzt in Zukunft auf den AMDGPU Teil im Kernel und einem neuen (umgebauten) Teil im Userspace, als Alternative zu mesa/radeosi.
Gibt es in Zukunft für neue AMD-Karten wirklich nur Open-Source Treiber? (für "normale" Endanwender)
Oder ist der neue Userspace-Treiber von AMD nur noch nicht verfügbar?...

Das ist ja wovon ich sprach, davon ist man zunächst ausgegangen, es wird aber definitiv in Zukunft noch zwei Stacks geben, die beide auf amdgpu basieren: "All Open" für "normale Endanwender", um deine Worte zu benutzen und den PRO Stack für FirePro Karten/Kunden. Die letzte offizielle Info ist ja erst vom September und auch sehr eindeutig:
full open stack:
Kernel Treiber amdgpu
DRM Treiber libdrm_amdgpu
X11-Treiber xf-86-video-amdgpu
3D-(OpenGL), Video (VDPAU, OpenMAX, also en- und decoding)-, Computing- (OpenCL) Treiber radeonsi (Mesa/Gallium)
die bisherige OpenCL Implementierung von AMD wird wohl als eigene Lösung weiterlaufen, also nicht in Gallium einfließen. Der Code wird aber freigegeben*
Vulkan Treiber: gleich wie bei OpenCL*

Deucher meinte auf der Konferenz, dass sie versuchen, es so schnell wie möglich zu machen, es aber gut sein kann, dass der Code zum Veröffentlichungszeitpunkt noch nicht freigegeben werden kann.
Hierbei muss man auch bedenken, dass es aus Patent- und Lizenzrechtlichen Gründen nicht ganz einfach ist, den kompletten Code einfach so zu veröffentlichen, zudem könnte dort ja auch noch externe IP drinstecken.

pro stack:
Kernel Treiber amdgpu
DRM Treiber libdrm_amdgpu
X11-Treiber xf-86-video-amdgpu
Video (VDPAU, OpenMAX, also en- und decoding): radeonsi (gallium)
OpenGL: closed
OpenCL, Vulkan: zunächst closed, eventuell später offen (s.o.)

http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf

 

[Stebs]

Das ist ja wovon ich sprach, davon ist man zunächst ausgegangen, es wird aber definitiv in Zukunft noch zwei Stacks geben, die beide auf amdgpu basieren: "All Open" für "normale Endanwender", um deine Worte zu benutzen und den PRO Stack für FirePro Karten/Kunden. Die letzte offizielle Info ist ja erst vom September und auch sehr eindeutig:

Danke, hab mir die PDF nochmal angeschaut. Bis jetzt hab ich das anders interpretiert als du, soo eindeutig sehe ich das aber immer noch nicht:
Da steht eigentlich nirgends eindeutig dass AMDs closed-source Catalyst™ UMD (der Name ist mittlerweile ja veraltet) NUR für FirePro Karten sein soll. Ich ging bis jetzt davon aus, dass man auch als "Normalo" mit den normalen Karten den nehmen kann um gleich bei dessen Erscheinen OpenGL 4.5 zu haben. Nur die FirePro Interfaces (der grüne Strich) wären dann evtl. nur den FirePro Karten vorenthalten.

Sprich: ein geschlossener User-Mode Treiber muss es wegen den professionellen Usern weiterhin geben (Workstation -> compatibility Profile usw.) und kann aber weiter von jedem genutzt werden (wegen OpenGL 4.5 JETZT). Am Open-Source UMD wird verstärkt gearbeitet und ist schon jetzt eine Alternative (wenn 4.2 reicht) und später bei erreichen von 4.5 wohl der Treiber der Wahl für jeden außer Pros.

 

[eruanno]

Dann habe ich deine Frage falsch verstanden. Ich meinte nicht, dass "normalos" nicht an den PRO Treiber ran kommen, sondern dass die beiden eben für verschiedene Use Cases sind und man als "normalo" sowieso den offenen bevorzugt. So eine Einschränkung könnte es natürlich theoretsich dennoch geben.
Letztes Jahr hieß es ja noch, dass es drei Stacks geben wird: all open, non-pro (amdgpu+catalyst) und pro (amdgpu, catalyst und die firepro addons). Daher gehe ich schon davon aus, dass es dabei bleibt und der pro-stack ausschließlich für FireGL Kunden gedacht ist.

 

[Zehkul]

Als "normaler" Nutzer sollte man aber auch oft übersehene OpenGL-nutzende Programme nicht vergessen. Von Media-Playern, Window-Manager/Compositor bis Browser.

Die funktionieren aber schon heute durch die Bank besser mit freien Treibern als mit den proprietären. Das schließt meiner Erfahrung nach auch den Nvidia Treiber ein, der ganze Desktop und alle Programme sind deutlich weniger flüssig auf meiner GTX670 als das mit den freien Treibern und einer 5770 der Fall war. Mit Mozplugger GL Fenster in Firefox einbetten geht so gut wie gar nicht mit Nvidia, muss in mpv VDPAU verwenden … Mir fällt spontan nichts ein, was mit Nvidia tatsächlich besser läuft. Catalyst ist da eine Katatrophe, wer nicht oder nur wenig spielt, ist mit den freien Treibern von vornherein besser bedient.

Eigentlich nicht, aber Tatsache ist, dass z.B. Unity3D unter Linux sebst mit der aktuellsten Version standardmässig max. OpenGL 2.1 nutzt (sich allerdings bei Verfügbarkeit auch "bessere" Extensions dazuholt.)
Das neue modernisierte und zusammengefasste OpenGL-Backend ist unter Linux noch experimentell. Vulkan ist angedacht, aber ohne konkreten Termin.

Ja, ich erwarte auch, dass die großen Engines tatsächlich langsamer sein werden als die Porter. Allen voran Unity, bei Unity hat derartiges einfach nicht so hohe Priorität, da geht es viel mehr um Usability für den Dev. Unreal dürfte aber da quasi open source zeitnah Support bekommen, war ja auch mit dem Linux Editior ähnlich.

Ich glaube dass DX11 Spiele auch weiterhin nach OpenGL4+ portiert werden (so wie Feral das zur Zeit macht) und dann nur DX12 Spiele nach Vulkan. Alles andere wären zu tiefgreifende Eingriffe in die originale Engine.

Und genau das glaube ich eben nicht! Tiefe Eingriffe in ein Spiel mögen Porter nicht, ja, aber deshalb vermeiden sie sie tunlichst ganz und verwenden translation Layers wie zum Beispiel besagtes togl von Valve. Der originale Renderer wird idealerweise gar nicht angefasst. Feral nennt deren Variante glaube ich IndirectX. Porter schreiben eben nicht jedes Mal einen Renderer neu, sondern stecken einfach den, den sie schon haben, in ein vorhandenes Spiel. Da ist es nicht allzu relevant, ob das nun ein OpenGL oder ein Vulkan Renderer ist. Bei vernünftiger Abstraktion sollten Updates der verwendeten Libraries auch leicht zu älteren Releases ausrollbar sein.

Ich erwarte ehrlich gesagt relativ bald nach Vulkan Launch, dass zumindest eON einen Vulkan Renderer kriegt und Updates auch zu älteren Releases ausgerollt werden. VP hat bisher alle eON Verbesserungen an alte Linux Releases weitergereicht, und zum Beispiel Bioshock Infinite würde es eine Menge bringen, das UE3 Texturstreaming ist nicht wirklich OpenGL kompatibel. Zu Feral und Aspyr weiß ich nix, aber Arkham Knight ist schon mal ein sehr guter Vulkan Kandidat. Auch UE3 und hat mit dem Streaming so große Probleme, dass es schon unter Windows nicht funktioniert.

Jedenfalls ist der momentan fehlende proprietäre AMD-Treiber für die neuesten GPUs ein echtes Problem für besagte moderne Spiele, die von Feral portiert werden und wurden.

Da bist du falsch informiert, da fehlt überhaupt nichts, das Catalyst Kernelmodul gibt es noch. Was es noch nicht gibt ist Catalyst GL auf freiem Kernelmodul.

 

[Stebs]

Letztes Jahr hieß es ja noch, dass es drei Stacks geben wird: all open, non-pro (amdgpu+catalyst) und pro (amdgpu, catalyst und die firepro addons). Daher gehe ich schon davon aus, dass es dabei bleibt und der pro-stack ausschließlich für FireGL Kunden gedacht ist.

Und ich dachte eben, dass sie mittlerweile erkannt haben dass der Open-Source Treiber zukünftig so gut werden kann, dass sie den proprietären nur noch für Legacy/Pro (Compatibility-Profile, Workstation-Extras) und zwischenzeitlich fehlende Features (OpenGL 4.3-5.5) brauchen. Da macht ein extra zu supportender closed-Source non-pro keinen Sinn.

Ist der neue closed-source UMD aber wirklich FirePro-only, würde ich mir mit einer neuen (auf amdgpu angewiesenen) GPU aber ziemlich verarscht vorkommen. Alien: Isolation und co. dann erst spielbar in ? einem Jahr?
Dafür momentan auf den neuen UMD warten zu müssen, ist doch schlimm genug.
Mit älteren Karten und dem Catalyst läufts zwar oft nicht toll, aber es läuft zumindest (wenn auch ohne offiziellen Support).

 

[Zehkul]

Und ich dachte eben, dass sie mittlerweile erkannt haben dass der Open-Source Treiber zukünftig so gut werden kann, dass sie den proprietären nur noch für Legacy/Pro (Compatibility-Profile, Workstation-Extras) und zwischenzeitlich fehlende Features (OpenGL 4.3-5.5) brauchen.

Das haben sie schon von Anfang an erkannt. Das sind nur verschieden Namen für ein und dasselbe, technisch hat sich nichts geändert. Catalyst GL auf freiem Kernelmodul kommt bald™, Mesa bleibt, jeder kann nutzen, was er will, niemand wird Catalyst nutzen, sobald Mesa besser ist, und AMD wird es auch nicht mehr nennenswert updaten. Tun sie ja jetzt schon kaum.

Die FirePro Addons sind open source und haben nach meinem Verständnis der Slides nichts mit OpenGL zu tun.

 

[Stebs]

Die funktionieren aber schon heute durch die Bank besser mit freien Treibern als mit den proprietären. Das schließt meiner Erfahrung nach auch den Nvidia Treiber ein, der ganze Desktop und alle Programme sind deutlich weniger flüssig auf meiner GTX670 als das mit den freien Treibern und einer 5770 der Fall war.

Hab ich schon öfters gehört, konnte ich aber auf meinem System mit Nvidia-Karte nicht beobachten (früher antike 8800GT, jetzt 560Ti). Desktop und Programme liefen sowohl mit nouveau oder Geforce flüssig, keine Probleme (nouveau natürlich nur keine Probleme, solange keine wirkliche Performance (kein reclocking) oder GL 4.2+ gebraucht wird).

Mit Mozplugger GL Fenster in Firefox einbetten geht so gut wie gar nicht mit Nvidia,

Mit mozplugger hab ich mal rumgespielt, war insgesamt nicht so tolle und brauch das dank livestreamer und ytube-dl nicht mehr

muss in mpv VDPAU verwenden …

Ja, DER Player schlechhin , aber da solltest du wenn möglich eh immer VDPAU nehmen, mit nouveau läufts aber hier nicht gescheit (wohl wieder zu niedrige Takte?)

Mir fällt spontan nichts ein, was mit Nvidia tatsächlich besser läuft.

Nun, alles was Performance oder OpenGL 4.2+ brauch.

Catalyst ist da eine Katatrophe, wer nicht oder nur wenig spielt, ist mit den freien Treibern von vornherein besser bedient.

Da hast du wohl Recht.
.

..aber deshalb vermeiden sie sie tunlichst ganz und verwenden translation Layers wie zum Beispiel besagtes togl von Valve. Der originale Renderer wird idealerweise gar nicht angefasst. Feral nennt deren Variante glaube ich IndirectX. Porter schreiben eben nicht jedes Mal einen Renderer neu, sondern stecken einfach den, den sie schon haben, in ein vorhandenes Spiel. Da ist es nicht allzu relevant, ob das nun ein OpenGL oder ein Vulkan Renderer ist. Bei vernünftiger Abstraktion sollten Updates der verwendeten Libraries auch leicht zu älteren Releases ausrollbar sein.

Ich mag mich irren, aber ich hab gehört dass "naives" dx10/11toVulkan und auch gltoVulkan performancemässig sehr schlecht sein soll, schlimmer als dxtogl, bei letzterem geht da schon einiges, aber Vulkan/DX12 soll zu prinzipiell verschieden sein. Aber seis drum, man wirds sehen.

Da bist du falsch informiert, da fehlt überhaupt nichts, das Catalyst Kernelmodul gibt es noch. Was es noch nicht gibt ist Catalyst GL auf freiem Kernelmodul.

Jetzt mal langsam (mangels derartigen Karte kenne ich mich da nicht so aus). Gibts es derzeit irgendeinen Treiber für die neuen AMD Fury Karten, der OpenGL 4.5 bietet? Ich dachte der Catalyst unterstützt die nicht mehr? Wenn doch, dann bin ich tatsächlich falsch informiert.
Dann hätte sich die Diskussion um den zukünftigen closed-Source UMD für Non-Pro als Zwichenlösung eh erledigt...

 

[Zehkul]

Ja, DER Player schlechhin , aber da solltest du wenn möglich eh immer VDPAU nehmen, mit nouveau läufts aber hier nicht gescheit (wohl wieder zu niedrige Takte?)

wm4 hat irgendwann letztes Jahr VDPAU in der Default Probing Reihenfolge nach hinten geschoben, opengl ist nicht ohne Grund Standard. Wenn ich mich richtig erinnere, dann war Nouveau sogar der direkte Grund dafür, und das einzige, was VDPAU wirklich besser konnte, war Frame Dropping, was der GL Renderer von mpv mittlerweile gut kann. Wenn du etwas anderes als opengl verwendest, verzichtest du auf eine ganze Reihe toller Features in mpv, von Scaling über color management zu verschiedenen Display Sync Methoden.

Ich mag mich irren, aber ich hab gehört dass "naives" dx10/11toVulkan und auch gltoVulkan performancemässig sehr schlecht sein soll, schlimmer als dxtogl, bei letzterem geht da schon einiges, aber Vulkan/DX12 soll zu prinzipiell verschieden sein. Aber seis drum, man wirds sehen.

Ich wüsste nicht, warum und habe auch nichts in der Richtung gehört. Was man an Mantle und DX12 gesehen hat, ist dass so ein Renderer recht schnell implementiert ist, aber dann eben noch längst nicht besser ist als der über lange Jahre in Treiber und Engine optimierte DX11 Pfad. Der Abstand ist aber nicht besonders groß – zumindest wenn man die Performance Einbußen gewöhnt ist, die Linux Ports eh schon haben (also aus Sicht eines Windows Benchmark Fanatikers „sehr schlecht“), bei OpenGL dürfte er deswegen kleiner sein und es ist praktisch unmöglich, langsamer als GL auf AMD Karten zu sein.

Jetzt mal langsam (mangels derartigen Karte kenne ich mich da nicht so aus). Gibts es derzeit irgendeinen Treiber für die neuen AMD Fury Karten, der OpenGL 4.5 bietet? Ich dachte der Catalyst unterstützt die nicht mehr?

Klar unterstützt der die. Der ganze Sinn hinter Catalyst ist es, jetzt Features zu liefern. Siehe Benchmarks auf Phoronix.

Es ist derzeit nicht einmal bestätigt, ob der kommende Catalyst user space Treiber auch wirklich auf Fiji und Tonga laufen wird – schließlich sind die schon über den alten Catalyst Stack unterstützt. Ich nehme es an, schlicht als Testlauf für die kommenden Karten, aber bestätigt ist nichts.

 

[Stebs]

wm4 hat irgendwann letztes Jahr VDPAU in der Default Probing Reihenfolge nach hinten geschoben, opengl ist nicht ohne Grund Standard. Wenn ich mich richtig erinnere, dann war Nouveau sogar der direkte Grund dafür, und das einzige, was VDPAU wirklich besser konnte, war Frame Dropping, was der GL Renderer von mpv mittlerweile gut kann. Wenn du etwas anderes als opengl verwendest, verzichtest du auf eine ganze Reihe toller Features in mpv, von Scaling über color management zu verschiedenen Display Sync Methoden.

Nun, es gibt ja zwei Einstellungen, die Hardwaredecodierung sollte das wenn möglich auf VDPAU stehen, also hwdec=vdpau.
Beim Video Output Treiber (vo= ) kann man wählen zwischen unter anderem opengl, opengl-hq und vdpau.
opengl-hq war lange Zeit bei mir eingestellt, aber mit vdpau hab ich noch eine Winzigkeit weniger CPU-Auslastung (bei aber eh niedrigen 1-4% CPU und dennoch super Qualität (besser als bei opengl, imho gleichwertig zu opengl-hq).
Scaling funktioniert definitiv auch mit hoher Qualität. Filter usw. sind mit vdpaupp video filter möglich. Über den funktioniert dann z.B. auch das "automatische" deinterlacing.
Mag sein dass dafür aber neueste VDPAU Versionen und Treiber benötigt werden, oder dass nouveau da schlechter ist.
Grad nochmal getestet: opengl-hq: 1-5,5% CPU, ein schwieriges AVC 1080p Video zum testen (das mit den tausend Gänsen).

Egal ob opengl-hq oder vdpau, mit dem Nvidia Treiber ist beides top, mir fehlt da nichts. (Mit der 8800GT wars z.B. merkbar besser als unter Windows).
Intels Mesa-Treiber (oder die Hardware der HD4000 GPU?) kann man mit opengl-hq und 4k mit 60 Hz aber in die Enge Treiben, mit opengl passts aber.
Gegenüber VLC und co. alles deutlich besser. Wobei gstreamer (1.x) selbst auch gut ist (was niedrige CPU-Auslastung angeht, per Kommandozeile), allein die Player mit Gstreamer-Unterstützung waren (damals?) eine Katastrophe und CPU-Auslastung war zu hoch.

Klar unterstützt der die. Der ganze Sinn hinter Catalyst ist es, jetzt Features zu liefern. Siehe Benchmarks auf Phoronix.

Ok, dachte eben, dass Catalyst GCN 1.2 Karten mit HBM Speicher gar nicht mehr unterstützt. Also wohl doch, nur stecken sie anscheinend keine Ressourcen mehr in die Optimierung.

Es ist derzeit nicht einmal bestätigt, ob der kommende Catalyst user space Treiber auch wirklich auf Fiji und Tonga laufen wird – schließlich sind die schon über den alten Catalyst Stack unterstützt. Ich nehme es an, schlicht als Testlauf für die kommenden Karten, aber bestätigt ist nichts.

Ja, da hatte ich gelesen, dass es sein könnte dass die momentane experimentelle Unterstützung ganz raus fliegt.

 

[Zehkul]

Nun, es gibt ja zwei Einstellungen, die Hardwaredecodierung sollte das wenn möglich auf VDPAU stehen, also hwdec=vdpau.
Beim Video Output Treiber (vo= ) kann man wählen zwischen unter anderem opengl, opengl-hq und vdpau.
opengl-hq war lange Zeit bei mir eingestellt, aber mit vdpau hab ich noch eine Winzigkeit weniger CPU-Auslastung (bei aber eh niedrigen 1-4% CPU und dennoch super Qualität (besser als bei opengl, imho gleichwertig zu opengl-hq)

Das kann nicht sein. Vdpau hat zwar eine hq scaling Option, aber die muss aktiviert werden und ist afaik auch erst ab PureVideo 4 unterstützt, 8800 GT ist 2. Ein kurzer Test zeigt auch, dass diese Option sich bei mir null auf Chroma Scaling auswirkt, nur Luma. Gilt übrigens auch für vdpau interop zu GL, wenn du hwdec=vdpau und vo=opengl mit besseren Scaling Optionen verwendest, übernimmt vdpau Chroma Scaling, egal was du dafür spezifizierst, was dann natürlich nur bilinear und damit schlechter ist. Qualität des Luma Scalings sieht auf den ersten Blick ziemlich identisch aus zu spline36 (Standard von opengl-hq, nur dass das es auch für Chroma anwendet)

CPU Auslastung ist auch nicht das, worauf du achten solltest, video rendering läuft über die GPU und opengl-hq beansprucht die dabei deutlich mehr. opengl-hq ist dabei übrigens nur ein Preset für opengl mit einigen Extras und man kann noch eine Menge andere Optionen dazuschalten, die bei höheren Auflösungen und Framerates dann auch die dicksten Gaming GPUs zum Schwitzen bringen. (Vor allem ewa_lanczos liefert dabei auch tatsächlich Mehrwert gegenüber den normalen nicht elliptischen Filtern) Also ja, es ist die Hardware, die bei Intel da nicht mitkommt. Die ein zwei Prozent der CPU verblassen dagegen total, aber auf extrem schwachen CPUs, wo ohne Hardware Decoding gar nichts geht, kann das durchaus schon was ausmachen, ja. Desktops sind aber immer stark genug.

Ja, da hatte ich gelesen, dass es sein könnte dass die momentane experimentelle Unterstützung ganz raus fliegt.

Tonga und Fiji ist nicht experimentell, Tonga und Fiji hat offiziellen Support im freien Treiber, da es beides GCN1.2 ist. GCN 1.1 ist experimentell in AMDGPU und könnte rausfliegen, da es schon in Radeon unterstützt ist, und wird daher ziemlich sicher nicht vom Catalyst Userspace Treiber unterstützt werden.