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

Zehkul schrieb:
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.
Zu 8800GT Zeiten hatte ich es auch noch auf opengl (oder opengl-hq)? stehen, jetzt ist wie gesagt eine 560Ti mit PureVideo4 drinnen.
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)
Ich komme da nicht ganz mit, du nutzt also hwdec=vdpau (ansonsten hättest du ja Softwaredecoding) und vo=opengl mit "custom" settings (dass opengl-hq ein preset ist, ist mir klar, die Doku dazu hab ich freilich gelesen) wie unter anderem einem besseren Scaler (+Chroma), das opengl-hq nicht defaultmässig macht (spline36)?
Egal, früher hab ich auch mit den speziellen Optionen rumgespielt, da sich da aber ständig so viel tut (Rolling Release, momentan mpv 0.13.0) und ich quasi keine Änderungen/Verbesserungen gemerkt habe, lasse ich es mittlerweile auf "default" opengl-hq (jetzt dann wieder) oder vdpau.
So oder so, z.B. Twitch 1080p -> 1600x1200 sieht um Welten besser aus als früher per Flash-Player im Browser.

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. ...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.
4k AVC fordern meinen Core2Duo @4 Ghz aber schon ganz gut, 60Hz dazu wär wohl zuviel. 1080p h265 ist auch absolut an der Grenze, alles reines Softwaredecoding natürlich, die 560Ti kann da nix mit Hardware.
Jedenfalls achte ich auf CPU und GPU, die HD4000 heizt mit opengl-hq deutlich mehr als mit "nur" opengl (CPU dabei quasi nix), ist mit dem Netbook auf dem Bauch schon merkbar, deshalb bleibts bei opengl (Korrektur: das habe ich auf vo=vaapi gestellt, nochmals deutlich weniger Hitze aus der GPU, Qualität von 720p (was fast immer geschaut wird) -> 1366 x 768 ist dabei gut und es funktioniert, abwohl wm4 beim Thema vaapi immer einen Anfall kriegt...)
Uff, wir sind langsam ganz schön offtopic...
 
Zuletzt bearbeitet:
Stebs schrieb:
Zu 8800GT Zeiten hatte ich es auch noch auf opengl (oder opengl-hq)? stehen, jetzt ist wie gesagt eine 560Ti mit PureVideo4 drinnen.

Ah, das habe ich überlesen.

Stebs schrieb:
Ich komme da nicht ganz mit, du nutzt also hwdec=vdpau (ansonsten hättest du ja Softwaredecoding)

Eigentlich nicht, nur fürs Testen eben.

Stebs schrieb:
und vo=opengl mit "custom" settings (dass opengl-hq ein preset ist, ist mir klar, die Doku dazu hab ich freilich gelesen) wie unter anderem einem besseren Scaler (+Chroma), das opengl-hq nicht defaultmässig macht (spline36)?

Ja, ist nicht default, denn ewa_lanczos verbrennt gut GPU, spline36 ist kein Vergleich. Dazu noch Interpolation … (tscale=mitchell)

Stebs schrieb:
Egal, früher hab ich auch mit den speziellen Optionen rumgespielt, da sich da aber ständig so viel tut (Rolling Release, momentan mpv 0.13.0) und ich quasi keine Änderungen/Verbesserungen gemerkt habe, lasse ich es mittlerweile auf "default" opengl-hq (jetzt dann wieder) oder vdpau.

Ja, mpv Entwicklung geht fix und ändert oft was an Kommandos und Optionen, auf Rolling Release Distros kann das durchaus nervig werden. (Ich nutze einfach git master und lese eh hier und da mit)

Wenn du keinen Unterschied bemerkst, denk dir nix dabei, da muss man teilweise schon sehr genau hinschauen bzw. gute Samples haben. Der Unterschied zu den elliptischen Scalern ist im Wesentlichen weniger Aliasing auf diagonalen Linien, fällt also nur bei gezeichneten Material mit scharfen Linien wirklich auf, Chroma Scaling ist noch seltener relevant, meist spielt in Luma die Musik. Für Chroma Scaling ist das hier ein schönes Beispiel, bei dem ewa_lanczos extrem gute Arbeit leistet:
http://a.pomf.cat/ihpvtx.mkv

Erm ja, off topic. Wie gesagt, für diese Anwendungen funktioniert der freie Treiber schon super. Es fehlen halt nur die letzten 20% an fps sowie die letzten 20% an OpenGL Features, relevant in Spielen und meinetwegen Blender oder so, dann ist Catalyst in allen Bereichen geschlagen. An Nvidia reicht Mesa damit aber noch lange nicht ran, deshalb wird Vulkan einfach essenziell sein für alle AAA Spiele, die ein Linux Release wagen wollen. Viele Entwickler wollen Vulkan auch schon für Vorhersagbarkeit, ich denke, auch unter Windows wird sich nächstes Jahr einiges tun. So schnell sich Windows 10 auch verbreitet, ein Release auf 25% des Marktes zu beschränken, muss schon wirklich gute Gründe haben. (Meist in Form von Geldscheinen von Sony :evillol:)

DX11 lässt sich scheinbar auch schon alles andere als ideal in OpenGL übersetzen, könnte gut sein, dass Vulkan hier einiges eher einfacher macht.
 
Zuletzt bearbeitet:
Inwieweit wäre das für Blender (speziell Cycles-Rendering) unter Linux relevant?
 
Wolfsrabe schrieb:
Inwieweit wäre das für Blender (speziell Cycles-Rendering) unter Linux relevant?
Cycles verwendet OpenCL. Das Thema aus der News hat nicht direkt damit zu tun. Natürlich ist es wichtig, dass die Taktraten stimmen, denn sonst geht die Performance natürlich auch beim Computing flöten. amdgpu ist "nur" der Kerneltreiber. Für OpenCL gibt es momentan die freie Implementierun als Teil von Gallium und AMDs Implementierung im Catalyst, die freigegeben werden soll. Siehe folgender Post:

eruanno schrieb:
full open stack:
[...]
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*
[...]

pro stack:
[...]
OpenCL, Vulkan: zunächst closed, eventuell später offen (s.o.)
http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf

Zu Gallium Compute kann ich sagen, dass es noch tief in der Entwicklung steckt. Cycles kannst du damit noch nicht verwenden. Wie es mit dem Catalyst aussieht, kann ich leider aktuell nicht sagen, sollte aber funktionieren, denke ich. Wenn der Umbau vollzogen ist, wird es dann sicherlich auch mit dem open stack funktionieren, das kann aber noch dauern.
 
Zuletzt bearbeitet:
Zurück
Oben