4k60Hz HEVC-Main10-Decoder: Nvidia GTX 1060 vs AMD RX 470?

[hikaru]

Ich würde eher tippen, dass du das file abgespielt hast, bevor es fertig gedownloaded war. Da hat der mpv dann Probleme beim spulen und macht die synchronität kaputt.

Ich habe die gesammte Sammlung seit Monaten auf meiner lokalen HDD. Da ist nichts mit Downloadproblemen.

Ziemlich exakt ab 30Hz sehe ich eh keine unterscheide mehr. (Ich habe mal ein bisschen rumgetestet: Die allermeisten Leute, die behaupten 50Hz würden ruckeln können es ebensowenig. Den unterschied von 50 auf 60Hz hat im Blindtest bei mir noch keiner sehen können. Aber alle sind davor überzeugt davon.)

Was man recht deutlich sieht ist, wenn Bildwiederholfrequenz und Monitor-Refresh-Rate zwar ähnlich sind, aber nicht ganz zueinander passen, also z.B. 50FPS-Material auf einem 60Hz-Monitor wiedergibt oder andersrum. Da gibt es recht häufige und v.a. regelmäßige Mikroruckler. Wenn man einmal das Muster erkannt hat, dann sieht man die andauernd - insbesondere bei Kameraschwenks mit klar konturiertem Bildinhalt.

Klar wir wir reden über h.265 und ich nehme mal das h.264 Video. Btw. gib's unter der entsprecheden URL gar keine h.264 Versionen. Domain heißt nicht umsonst www.libde265.org. Und selbstverständlich gieng es immer um Echtzeit.

Du hast nicht geschrieben, woher du die Videos hattest. Falls du die wie ich schon auf der HDD zu liegen hattest oder für Testzwecke beide Codierungen parallel gezogen hast, kann man sich schnell mal im Ordner vertun.

Was mich stutzig macht ist, dass bei dir offenbar alles so wunderbar läuft während bei mir (2700k) und unter Windows bei Lord_Carlos ohne Hardwarebeschleunigung nichts Brauchbares heraus kommt. Es kann also nicht nur daran liegen, dass ich mich zu blöd anstelle. Und dass dein FX-8370 in dem Szenario geschätzt um Faktor 2 schneller sein soll als sein 5820k glaube ich nicht.

Du könntest mal den VLC probieren. Der nutzt eigene codecs. Aber der ist bei mir mit h.265 nicht zu nutzen.

Der zeigte bei mir unter Jessie bei h265 nur ein grünes Bild und schon h264 in 4k60 war grenzwertig. Ähnliches auch mit parole und einigen anderen Playern die ich nicht mehr im Kopf habe (meine erste Testrunde ist schon ein paar Monate her).
mpv stellte sich insgesamt am besten an, denn da war die Wiedergabe wenigstens sauber, wenn auch langsam.

[Lord_Carlos]

Als ich mein CPU auf 6x 4.3 uebertaktet habe ging es nach wenigen sekunden ruckler auch fluessig. Jedenfalls soweit ich es beurteilen kann.
Aber das ist total egal weil ich keine lust habe Filme mit 75%+ CPU last zu gucken.

Ich sehe zur Zeit GPU decoding als das einzig brauchbare. Ob das nun manchmal ruckkelt oder immer ist, oder ob 50fps gerade so gehen oder es 48 sind. Kack egal, GPU rein, film gucken mit max 1% CPU last und fertig ist das. Kein Plan warum hier noch CPU vs. GPU diskutiert wird.

Ganz ganz vielleicht kann ich die Tage mal linux installieren. Versprechen werde ich das aber nicht.

[wanne]

Da gibt es recht häufige und v.a. regelmäßige Mikroruckler. Wenn man einmal das Muster erkannt hat, dann sieht man die andauernd - insbesondere bei Kameraschwenks mit klar konturiertem Bildinhalt.

Ich höre das immer wieder und trotzdem hat es keiner im sauber Blindtest hinbekommen. Gab immer false Positives.

Falls du die wie ich schon auf der HDD zu liegen hattest oder für Testzwecke beide Codierungen parallel gezogen hast, kann man sich schnell mal im Ordner vertun.

Auf der einer externen HDD. (bzw. normale HDD in docking station.) Hätte ich als extra anstecken und mounten müssen. Außerdem ist alles 4k Material auf meiner platte h.265.

Und dass dein FX-8370 in dem Szenario geschätzt um Faktor 2 schneller sein soll als sein 5820k glaube ich nicht.

Faktor 2 kommt mir auch extrem vor. Aber der FX-8370 ist eben ein 8-Kerner und mit caches und allem wirklich auf 4GHz ausgelegt. Solage da nicht die miese AMD-Floatingpoint Performance reinspielt ist der echt ordentlich. Bei den schön optimierten Codecs macht der halt wirklich praktisch acht Operationen Takt. Und zum i7-2600K der mit 4-Kernen auf 3,4Ghz ausgelegt ist, ist das halt ein ordentlicher unterschied. Da kommst du nämlich wenn du ihn auf 4GHz hoch taktest nicht auf 4 OPs pro Takt.
Das ist halt was völlig anderes, wenn du ein Spiel spielst, dass meist sowieso auf Intel optimiert ist und vor allem die bessere branch prediction und Floatingpoint performance etc. den schnelleren Gesamttakt des AMDs mehr als zunichte machen. Und vor allem der Intel seinen Turbo ausspielen kann. Dazu kommt der defakto "fehlende" L2-Cache. (L2-Cache ist shared und angeblich so langsam wie Intels L3-Cache.) Gibt nicht viele Anwendungen, wo ich den FX über die 300% bekomme und wenn ist das wahrscheinlich nur selten wirklich nützlich. Die Ineffizienz ist es, die die Intels in den meisten Fällen so viel besser aussehen lassen. Aber wenn dann ist er halt schon ein ziemliches Monster.
Aber defakto hat sich das je eh erledigt. Neue Grafikkarte muss eh her, wenn die 8800 GT eh nur 1080p kann. Wobei mich das extrem wundert. Selbst meine Intels GMA 4500 MHD von vor Ewigkeiten können doch über 8000x8000. Von ihren Leistungsdaten müsste die doch locker auf 16000*8000 oder so kommen du nutzt den vouveau? nvidia ist da immer irgendwie knickerig bei der Auflösung.

Du könntest mal den VLC probieren. Der nutzt eigene codecs. Aber der ist bei mir mit h.265 nicht zu nutzen.

Der zeigte bei mir unter Jessie bei h265 nur ein grünes Bild und schon h264 in 4k60 war grenzwertig. Ähnliches auch mit parole und einigen anderen Playern die ich nicht mehr im Kopf habe (meine erste Testrunde ist schon ein paar Monate her).
mpv stellte sich insgesamt am besten an, denn da war die Wiedergabe wenigstens sauber, wenn auch langsam.[/quote]Hier macht er zumindest bunte Bilder. Und ich meine, dass es ansatzweie etwas mit dem Film zu tun hat . Und h.264 läuft wirklich. Btw. macht dragon player bei mir kleine Artefakte in h.265 Material. Kann das irgend jemand bestätigen?

[hikaru]

Da gibt es recht häufige und v.a. regelmäßige Mikroruckler. Wenn man einmal das Muster erkannt hat, dann sieht man die andauernd - insbesondere bei Kameraschwenks mit klar konturiertem Bildinhalt.

Ich höre das immer wieder und trotzdem hat es keiner im sauber Blindtest hinbekommen. Gab immer false Positives.

False Positivers sind schlimmer als False Negatives.
Wenn du echte Mikroruckler siehst und weißt, dass welche da sind, dann bildest du dir auch irgendwann welche ein. Und das trübt den Filmgenuss, ganz subjektiv.

Aber der FX-8370 ist eben ein 8-Kerner und mit caches und allem wirklich auf 4GHz ausgelegt. Solage da nicht die miese AMD-Floatingpoint Performance reinspielt ist der echt ordentlich. Bei den schön optimierten Codecs macht der halt wirklich praktisch acht Operationen Takt.

Das ergäbe Sinn. Aber sind denn die zwei Integer-Kerne pro Modul wirklich vorhanden? Ich dachte, das wäre so eine Art Hyperthreading wie bei Intel.

Und zum i7-2600K der mit 4-Kernen auf 3,4Ghz ausgelegt ist, ist das halt ein ordentlicher unterschied. Da kommst du nämlich wenn du ihn auf 4GHz hoch taktest nicht auf 4 OPs pro Takt.

Tippfehler?

Neue Grafikkarte muss eh her, wenn die 8800 GT eh nur 1080p kann. Wobei mich das extrem wundert. Selbst meine Intels GMA 4500 MHD von vor Ewigkeiten können doch über 8000x8000. Von ihren Leistungsdaten müsste die doch locker auf 16000*8000 oder so kommen du nutzt den vouveau? nvidia ist da immer irgendwie knickerig bei der Auflösung.

1. Die 8800GT kann 2560x1600 ausgeben, aber der Fernseher meldet unter 4k nur 1080p. Ob dazwischen etwas mit manuellen Modelines ginge habe ich nicht getestet. Bei einer 4k-Modeline gibt die Grafikkarte jedenfalls nichts aus.
2. Die 8000x8000 deiner GMA sind der virtuell adressierbare Desktop. Ob das über den verbauten Grafikausgang tatsächlich ausgegeben werden kann ist eine andere Frage. Für 4k braucht man halt HDMI 2.0 oder Displayport 1.4. Beides hat eine 8800GT von 2007 oder 2008 nicht.

Btw. macht dragon player bei mir kleine Artefakte in h.265 Material. Kann das irgend jemand bestätigen?

Das ist doch nur ein vlc-Frontend (via phonon), oder? Das lässt zumindest die Ausgabe im Terminal vermuten.
Bei mir stirbt der mit einem Segfault, wenn ich ihm ein 4k-Video vorwerfe, egal ob h264 oder h265. Die kleineren h265-Jellyfish-Videos werden aber auf dem Sandy.-Bridge-IGP problemlos abgespielt.

[wanne]

Aber sind denn die zwei Integer-Kerne pro Modul wirklich vorhanden?

Klar. Die Begründung seitens AMD ist, dass Float ja dank SIMD-Register ja zwei mal 64Bit in einer Operation machen kann. Mit AVX sogar hat man ja sogar 256Bit. Intel kann aber eben sogar AVX-512. Und das bei vollen Float Einheiten pro Kern.

Ich dachte, das wäre so eine Art Hyperthreading wie bei Intel.

Intel bezeichnet AMDs Dinger immer als Hyperthreaddet. Was aber eben quatsch ist.

Ob das über den verbauten Grafikausgang tatsächlich ausgegeben werden kann ist eine andere Frage. Für 4k braucht man halt HDMI 2.0 oder Displayport 1.4.

LVDS wäre noch ne alternative. Ansosnten reicht für 4k@60Hz DP1.2 Oder vor allem 2xHDMI 1.4 So machen das viele Geräte für 5K. Ist aber ein übler Hack, mit dem man eigentlich nicht arbeiten will.

Das ist doch nur ein vlc-Frontend (via phonon), oder? Das lässt zumindest die Ausgabe im Terminal vermuten.

ich dachte, das wäre gstreamer. Aber installiert ist bei mir auch phonon-backend-vlc auf jeden Fall tut es sich anders verhalten als der VLC player.


Aber hier mal ein Test auf einem anderen Recher: 5k-Bildschirm, Nvidia GTX980 => Kein h.265 in HW.
Was der WMP auch so angibt.
Windows 8, Windows Mediaplayer Classic i7 Hexacore. Habe leider vergessen was es genau war. Glaub i7-5xxx auf nem 2011-3 Sockel:
h265-Jellyfish, 250 Mbps: keine Framedrops, aber ruckelt an einer stelle.
h265-Jellyfish, 400 Mbps: 1 Framedrop, aber ruckelt an der selben stelle. Bin mittlerwele überzeugt, dass das Original kaputt ist.
BBB spielt Synchron ohne Probleme 3 Framedrops am Anfang.
Btw. hat man bei dem Ding kein Ton von der Lüftung gehört. Konnte echt nicht sagen, ob der an oder aus ist. Hat aber wohl ziemlich viel für seinen Kühlkörper hingelegt. Trotz allem beeindruckend. Die grafikkarte wird im übrigen laut, wenn man sie beansprucht.

Hätte sogar Beweißwiedeos mit dem Handy. Da kann man auch wunderbar sehen, dass das eindeutig 4k sind .

[ralli]

@hikaru schau mal hier,

http://www.geforce.com/hardware/desktop ... ifications

das ist die offizielle Spezifikation für meine Nvidia Geforce 9500 GT, da wird eine maximale Auflösung von

Maximum Digital Resolution - 2560x1600
Maximum VGA Resolution - 2048x1536

angegeben, der offizielle propertiäre Nvidia Treiber bietet unter nvidia-settings und xrandr aber nur bis 1600x900 an. Da wird wohl, wenn es denn überhaupt möglich ist, eine manuelle Konfiguration der xorg.conf nötig sein.

[tegula]

[...] Wobei mich das extrem wundert. Selbst meine Intels GMA 4500 MHD von vor Ewigkeiten können doch über 8000x8000. [...]

http://www.intel.com/Assets/PDF/datasheet/319970.pdf, Seite 20:

[...] Flat panels up to 2048x1536 @ 60 Hz [...]

[hikaru]

Aber sind denn die zwei Integer-Kerne pro Modul wirklich vorhanden?

Klar. Die Begründung seitens AMD ist, dass Float ja dank SIMD-Register ja zwei mal 64Bit in einer Operation machen kann. Mit AVX sogar hat man ja sogar 256Bit. Intel kann aber eben sogar AVX-512. Und das bei vollen Float Einheiten pro Kern.

Ich verstehe die Erklärung nicht. Was hat die Registerbreite mit der Anzahl der ALUs zu tun?

LVDS wäre noch ne alternative.

Hab ich bei Consumer-Grafikkarten noch nicht als Ausgang gesehen, und bei Fernsehern noch nicht als Eingang.

Ansosnten reicht für 4k@60Hz DP1.2

Stimmt.

Oder vor allem 2xHDMI 1.4 So machen das viele Geräte für 5K. Ist aber ein übler Hack, mit dem man eigentlich nicht arbeiten will.

Eben.

Aber hier mal ein Test auf einem anderen Recher: 5k-Bildschirm, Nvidia GTX980 => Kein h.265 in HW.
Was der WMP auch so angibt.
Windows 8, Windows Mediaplayer Classic i7 Hexacore. Habe leider vergessen was es genau war. Glaub i7-5xxx auf nem 2011-3 Sockel:
h265-Jellyfish, 250 Mbps: keine Framedrops, aber ruckelt an einer stelle.
h265-Jellyfish, 400 Mbps: 1 Framedrop, aber ruckelt an der selben stelle. Bin mittlerwele überzeugt, dass das Original kaputt ist.
BBB spielt Synchron ohne Probleme 3 Framedrops am Anfang.

Schon erstaunlich! Angenommen, da steckt ein 5930k mit Standardtakt drin, dann käme der wohl auf 240 GIPS Dhrystone. [1]
Mein 2700k käme mit Standardtakt auf 140 GIPS und mit 4,7GHz auf 175 GIPS. [2] Das sieht linear aus, also würde ich bei meinen 4,2GHz gut 160 GIPS erwarten. Das sind beim 5930k interessanterweise genau die 50% mehr, die durch die beiden zusätzlichen Cores dazukommen.
Für das 400MBit/s-Jellyfish-Video muss ich in mpv auf ziemlich genau 1/3 der der Abspielgeschwindigkeit gehen, damit es sauber läuft. Beim 5930k würde ich also irgendwas um halbe Geschwindigkeit erwarten. Lass da ruhig noch weitere 20-30% Architektur- und Softwareoptimierung drinstecken. Unter'm Strich würde ich nicht erwarten, dass das in Software geht. Ist die CPU zufällig auch noch übertaktet?

Btw. hat man bei dem Ding kein Ton von der Lüftung gehört. Konnte echt nicht sagen, ob der an oder aus ist. Hat aber wohl ziemlich viel für seinen Kühlkörper hingelegt. Trotz allem beeindruckend.

Die in Frage kommenden CPUs haben alle eine TDP von 140W. Das lässt sich mit einem wirklich guten Luftkühler noch ohne zu zaubern wegschaffen, mit etwas Kompromissbereitschaft bei der Temperatur auch noch leise. Mein übertakteter 2700k verbrät geschätzt 150W (System mit 210W gemessen vs. 160W bei Standardtakt, aber ich kann die CPU nicht sauber vom Rest trennen). Das kriege ich in einem Miditower noch auf 80°C gekühlt, ohne dass die Lüfter lauter werden als die beiden 3,5"-HDDs. In einem auf gute Kühlung ausgelegten Bigtower ginge das sicher noch besser.


@ralli:
Die von der Grafikkarte als maximal möglich angegebene Auflösung hängt auch vom Monitor ab. Der sendet ein EDID-Signal in dem er der Grafikkarte mitteilt, was er kann. Der Treiber sollte dann nur die vom Monitor mitgeteilten Auflösungen anbieten.
Die frühen Monitore die mehr als 1920x1200 konnten sendeten z.B. teils keine EDID-Signale über dieser Auflösung, vermutlich weil da noch alte EDID-Chips verbaut waren. Um das zu umgehen gab es dann ab Werk modifizierte Windowstreiber die zusätzliche Modelines enthielten die sich nicht aus dem EDID-Signal ergaben. Genau das Gleiche ist unter Linux möglich, entweder per xorg.conf oder per xrandr.
Ich hatte der 8800GT mit xrandr eine Modeline für 3840x2160 mitgegeben. Es gab keine Fehlermeldung, die Grafikkarte schaltete auch um, aber der Fernseher sagte, es käme kein Signal an.


[1] http://ocaholic.ch/modules/smartsection ... ang=german
[2] http://www.au-ja.de/review-intel-core-i7-2700k-11.phtml

[ralli]

@hikaru, danke, gut zu wissen. Geahnt hatte ich es schon, aber nicht gewußt. Das macht aber wahrscheinlich auch Sinn, um den Monitor dann vor Übertaktung zu schützen, oder?

[hikaru]

Das macht aber wahrscheinlich auch Sinn, um den Monitor dann vor Übertaktung zu schützen, oder?

Zumindest war das früher bei CRT-Monitoren so. Wenn man die mit zu hohen Frequenzen angesteuert hat, dann konnten die Schaden nehmen. Ich habe Ende der 90er mal erlebt wie sich ein damals fast 10 Jahre alter Monitor beim Versuch ihn mit 85Hz anzusteuern mit einem lauten "Zapp" für immer verabschiedete. Von außen war nichts zu sehen und es roch auch nicht verdächtig. Die Lampe des Power-Knopfes ging danach beim Einschalten auch noch an, aber die Röhre brachte kein Bild mehr.

Ob das heute noch eine Rolle spielt weiß ich nicht. LCD-Displays ist das egal. Die verweigern im schlimmsten Fall den Dienst bis man ihnen wieder ein genehmeres Signal anbietet. Was dazwischen in der Elektronik passiert weiß ich nicht. Aber ich könnte mir zumindest theoretisch vorstellen, dass sich eine schlampig programmierte Firmware bei unpassendem Input unrettbar verschluckt. Erlebt habe ich es noch nicht.

[Lord_Carlos]

Gerade debian installieren. Geht unter Linux wohl noch nicht. Vdpauinfo gibt folgendes aus: https://openbenchmarking.org/system/160 ... /vdpauinfo

Code: Alles auswählen

H264_HIGH_444_PREDICTIVE       41 65536  4096  4096
HEVC_MAIN                      153 262144  8192  8192
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Soll ich irgendetwas testen?

[hikaru]

Soll ich irgendetwas testen?

Ja. Kannst du bitte mal testen, ob das 4k-Video von Big Buck Bunny [1] hardwarebeschleunigt läuft?
Das ist im Main-Profil und wenn ich deine Ausgabe richtig deute, dann müsste das unterstützt werden. Es hat zwar nur irgendwas um 15MBit/s, aber das sollte zum Testen ob Hardwarebeschleunigung überhaupt funktioniert reichen.
Eines der FullHD-Jellyfish-Videos in h265 sollte auch gehen.

Danke für die Mühe!


[1] http://www.libde265.org/downloads-videos/

[guennid]

Ich habe Ende der 90er mal erlebt, wie sich ein damals fast 10 Jahre alter Monitor beim Versuch, ihn mit 85Hz anzusteuern, mit einem lauten "Zapp" für immer verabschiedete.

Schade, da fehlt mir irgendwie eine Erfahrung: Ich habe es noch nie fertiggebracht, hardware mit software einfach abzuschießen. Ist aber eigentlich auch gut so, denn ich hatte es noch nie so richtig dicke.

Grüße, Günther

[Lord_Carlos]

Ich schaffe es nicht mpv zu compilieren. 39439

Wenn ich dpkg-buildpackage -uc -us -b -j4mache findet ld eine libEGL nicht .. obwohl die da ist.

[wanne]

Ich verstehe die Erklärung nicht. Was hat die Registerbreite mit der Anzahl der ALUs zu tun?

Eigentlich nichts. ist halt Marketing geblubber. Die Erklärung ist halt folgende: Mit SSEX.X kannst du zwei 64-Bit doubles in ein 128MMX-Reister stecken und die dann mit einer Operation beide gleichzeitig verarbeiten. Deswegen braucht man laut AMD nur halb so viele Einheiten. Auf der andren Seite muss der Prozessor halt auch die doppelte (bei AVX sogar die vierfache) Datenmeng fechten. Weshalb die gleiche Anzahl an Floatingpoint Einheiten halt das ganze Prozessordsighn vergrößert was die Prozessoren halt unverhätnismäßig teurer macht.

Hab ich bei Consumer-Grafikkarten noch nicht als Ausgang gesehen

Die ganzen Mobilen wie die genannte von Intel haben das alle.

Unter'm Strich würde ich nicht erwarten, dass das in Software geht. Ist die CPU zufällig auch noch übertaktet?

Garantiert nicht übertaktet. Und da lief noch einiges im hintergrund (Firefox, Torrentclient...) Schien das System ganz und gar nicht an seine Leistungsgrenzen zu bringen.
Deswegen bin ich ja so verwundert, dass du da ganz und gar nicht ran kommst. Ich tippe, dass da irgend wo noch ein anderes Bottleneck sein muss.
Hatte z.B. mal einen Mini PC der HD-h.263-Videos zwar ohne Probleme live konvertieren konnte aber an der Ausgabe gescheitert ist. Mein Tipp damals war, dass der schlicht nicht genug durch seinen PCI-Bus bekommen hat.

PS: Sorry für die falsche Abkürzung gemeint war natürlich mpc nicht der WMP.

[wanne]

Gerade debian installieren. Geht unter Linux wohl noch nicht. Vdpauinfo gibt folgendes aus: https://openbenchmarking.org/system/160 ... /vdpauinfo

Code: Alles auswählen

H264_HIGH_444_PREDICTIVE       41 65536  4096  4096
HEVC_MAIN                      153 262144  8192  8192
HEVC_MAIN_10                   --- not supported ---
HEVC_MAIN_STILL                --- not supported ---
HEVC_MAIN_12                   --- not supported ---
HEVC_MAIN_444                  --- not supported ---

Was interessanter weise genau das ist, was in der Doku von nvidia steht.

[Lord_Carlos]

Ich habe jetzt mpv aus den sourcen installieren.

mpv braucht ca. 200 - 300% cpu fuer den bunny film.
mit --hwdec='vdpau' kommt es zu grafikfehlern, aber nur noch ~15% auslastung.

[hikaru]

Schade, da fehlt mir irgendwie eine Erfahrung: Ich habe es noch nie fertiggebracht, hardware mit software einfach abzuschießen.

Oh, das geht teils sehr einfach. Als Student hatte ich mal irgendwo gelesen, dass man Tastaturen dadurch schrotten kann, dass man in sehr kurzen Abständen (deutlich unter einer Sekunde) die Status-LEDs ein- und ausschaltet. Ich war neugierig und hatte eine Tastatur über, also habe ich ein Programm geschrieben das genau das gemacht hat. Nach etwa einer Minute schaltete die LED nicht mehr und die Tastatur reagierte auch nicht mehr auf Eingaben, selbst nach einem Reboot und umstecken an einen anderen Rechner.

So weit, so schlecht ... könnte man meinen. Aber da ich damals schon Vorlesungen in Statistik hatte ahnte ich, dass das ein zufälliger Ausreißer sein könnte. Also führte ich den selben Test mit einer zweiten Tastatur durch, und kam zum selben Ergebnis. Hoch zufrieden ein statistisch signifikantes Ergebnis erzielt zu haben ging ich ins Bett, es wurde schließlich bald wieder hell.
Am nächsten Morgen fuhr ich nicht mehr ganz so zufrieden in die Stadt, denn ich hatte vor dem Experiment wirklich nur genau EINE Tastatur über.

Ich verstehe die Erklärung nicht. Was hat die Registerbreite mit der Anzahl der ALUs zu tun?

Eigentlich nichts. ist halt Marketing geblubber. Die Erklärung ist halt folgende: Mit SSEX.X kannst du zwei 64-Bit doubles in ein 128MMX-Reister stecken und die dann mit einer Operation beide gleichzeitig verarbeiten. Deswegen braucht man laut AMD nur halb so viele Einheiten. Auf der andren Seite muss der Prozessor halt auch die doppelte (bei AVX sogar die vierfache) Datenmeng fechten. Weshalb die gleiche Anzahl an Floatingpoint Einheiten halt das ganze Prozessordsighn vergrößert was die Prozessoren halt unverhätnismäßig teurer macht.

Der Aufhänger für mein Unverständnis ist, warum du jetzt überhaupt mit FLOPS argumentierst. Vorher [1] hast du die gute Performance deines AMD beim Decodieren von h265 damit begründet, dass er besonders gut im Integerbereich ist, während du an anderer Stelle [2] herausgestellt hast, dass AMD nicht sonderlich gut bei FP abschneidet.

Hab ich bei Consumer-Grafikkarten noch nicht als Ausgang gesehen

Die ganzen Mobilen wie die genannte von Intel haben das alle.

Die kann man aber nicht im Laden kaufen und nachträglich in seinen Desktop-Rechner stecken. Abgesehen davon habe ich auch bei noch keinem Laptop ein nach außen geführtes LVDS gesehen.

Deswegen bin ich ja so verwundert, dass du da ganz und gar nicht ran kommst. Ich tippe, dass da irgend wo noch ein anderes Bottleneck sein muss.

Ich wüsste nicht was. Der PCI-Bus ist bei mir in Bezug auf das Szenario arbeitslos. Die GPU steckt in der CPU und macht außer der reinen Ausgabe nichts, die HDDs sind bei weitem nicht ausgelastet (außerdem hatte ich auch schon mal versucht ein Video aus dem RAM abzuspielen) und die 16GB RAM sind bei den Tests für gewöhnlich mindestens zur Hälfte leer während die CPU Däumchen drehen würde, wenn sie nicht Decodieren müsste.

Ich habe jetzt mpv aus den sourcen installieren.

mpv braucht ca. 200 - 300% cpu fuer den bunny film.
mit --hwdec='vdpau' kommt es zu grafikfehlern, aber nur noch ~15% auslastung.

Sehr schön! Das deutet zumindest darauf hin, dass h265-Decodierung priinzipiell funktioniert.

Ich habe mir einen Jessie-Backport für mpv aus den Stretch-Quellen gebaut und komme damit auf leicht bessere Ergebnisse als mit der selben mpv-Version unter Fedora. Ein Problem auf Softwareseite schließe ich also aus. Ich kann jetzt BBB in 4k bei 75% Geschwindigkeit und 200-350% CPU-Last abspielen. Wenn die Last über 400% steigt, dann kommt es zu Framedrops. Ich vermute, dass Hyperthreading beim Decodieren einfach nicht hilft.
Kannst du als Gegentest bitte mal bei Softwaredecodierung die Abspielgeschwindigkeit erhöhen (schließende eckige Klammer ] ), bis du über 600% kommst, also Hyperthreading nötig würde und auf die Framedrops achten?


[1] viewtopic.php?f=13&t=161817#p1100782
[2] viewtopic.php?f=28&t=161777#p1100222

[wanne]

Der Aufhänger für mein Unverständnis ist, warum du jetzt überhaupt mit FLOPS argumentierst. Vorher [1] hast du die gute Performance deines AMD beim Decodieren von h265 damit begründet, dass er besonders gut im Integerbereich ist, während du an anderer Stelle [2] herausgestellt hast, dass AMD nicht sonderlich gut bei FP abschneidet.

Da ging einiges durcheinander. Ich habe da eigentlich immer zitiert, auf welchen Betrag sich das Bezog.
Gunsätzlich gilt das

1. Auf den AMDs von uns läuft das ganze. Bei deinen Intels nicht.
2. Nun ist die Frage ob das an der schlechteren decodierleistung deiner Intels oder an irgend etwas anderem liegt.
3. Benchmarks, die die Performance von AMDs und Intels vergleichen gibt es aber praktisch nur zu FP-Performance.
4. Effizientere Codecs arbeiten aber mit Integer.
5. Das Verhältnis zwischen Integer und Float Performance ist bei AMDs deutlich anders als bei Intels.
6. Als Nebeninformation habe ich abgegeben, wie AMD begründet, dass sie ein so viel anderes Verhältnis zu den Intels wählen.

[hikaru]

Auf den AMDs von uns läuft das ganze. Bei deinen Intels nicht.
Nun ist die Frage ob das an der schlechteren decodierleistung deiner Intels oder an irgend etwas anderem liegt.

Da Lord_Carlos unter Berücksichtigung seiner stärkeren CPU vergleichbare Ergebnisse erzielt wie ich, denke ich nicht, dass es an MEINEM Intel liegt.

Benchmarks, die die Performance von AMDs und Intels vergleichen gibt es aber praktisch nur zu FP-Performance.

Zu beiden gibt es Dhrystone-Benchmarks mit der selben Software (SiSoft Sandra).

Als Nebeninformation habe ich abgegeben, wie AMD begründet, dass sie ein so viel anderes Verhältnis zu den Intels wählen.

Hier hast du begründet, warum AMD meint, es reiche ein Modul mit einer FPU auszustatten:

Aber sind denn die zwei Integer-Kerne pro Modul wirklich vorhanden?

Klar. Die Begründung seitens AMD ist, dass Float ja dank SIMD-Register ja zwei mal 64Bit in einer Operation machen kann. Mit AVX sogar hat man ja sogar 256Bit. Intel kann aber eben sogar AVX-512. Und das bei vollen Float Einheiten pro Kern.

Das erklärt aber nicht, ob ein Modul wirklich zwei ALUs hat oder nur eine ALU die Hyperthreading kann, was ja meine Frage war.

[hikaru]

Der offene Treiber für Polaris kann wohl noch keinen Ton über HDMI. [1] Mindestens bis Kernel 4.9 raus ist müsste ich also wohl den proprietären Treiber [2] verwenden, der zwar als Debian-Pakete verfügbar ist, aber nur für Ubuntu und SteamOS (das immerhin auf Jessie basiert).

[1] http://www.phoronix.com/scan.php?page=n ... -DAL-Audio
[2] http://support.amd.com/en-us/kb-article ... stall.aspx

[wanne]

Zu beiden gibt es Dhrystone-Benchmarks mit der selben Software (SiSoft Sandra).

Kannst du mal verlinken?

Das erklärt aber nicht, ob ein Modul wirklich zwei ALUs hat oder nur eine ALU die Hyperthreading kann, was ja meine Frage war.

Die habe ich zwei mal eindeutig beantwortet. Zwei ALUs pro Modul.

Aber sind denn die zwei Integer-Kerne pro Modul wirklich vorhanden?

Klar.

Außerdem ergibt sie sich auch aus der Antwort. Woher sollen sonst halb soviele FP einheiten kommen? Btw. ist wohl anzumerken, dass ich Intel da wohl etwas unrecht getan habe, als ich ihnen angehängehängt habe dass sie AMDs Mehrkernprozessoren als lediglich Hyperthreadded dargestellt haben. Zumindest die K9er (Opterons, Athlon64 X2) (Die sogar wirklich volle 2 Kerne mit 2 FP-Einheit hatten.) Hat AMD selbst als Einprozessorsysteme 2 fach Hyperthreaded bezeichnet. Intel hat die Marketingsteilvorlage natürlich dankend angenommen.

[hikaru]

Zu beiden gibt es Dhrystone-Benchmarks mit der selben Software (SiSoft Sandra).

Kannst du mal verlinken?

Für die beiden Intels von Lord_Carlos und mir hatte ich das in [1] schon getan. Für deinen FX-8350 gibt es unter [2] Dhrystone-Vergleiche zu diversen anderen CPUs, darunter ein i7-2600k, dessen Wert in Anbetracht des geringen Taktunterschiedes so gut zu meinem 2700k passt, das ich davon ausgehe, dass man den Werten bis auf 2 oder 3% vertrauen kann.
Werte zum von dir empfohlenen FX-9370 und drei anderen CPUs (darunter ein FX-9590) gibt es unter [3] (Scripte!). Hier habe ich keine Plausibilitätsprüfung gemacht.

Ich habe übrigens gestern Abend versucht einen Jessie-Backport für mesa aus Experimental zu bauen. Dazu brauche ich diverse andere Backports. Dabei ist mir über Nacht beim Bauen von llvm-toolchain-3.8 die virtuelle 20GB-Platte vollgelaufen. Ich habe den Umfang des Pakets einfach unterschätzt. Alle anderen Pakete davor waren Fragen von Minuten und wenigen 100MB. Momentan läuft ein zweiter Versuch mit größerer Platte.


[1] viewtopic.php?f=13&t=161817&start=30#p1101075
[2] http://www.guru3d.com/articles-pages/am ... ew,11.html
[3] http://www.overclockersclub.com/reviews ... 9370/6.htm

[hikaru]

Mir wurden die Unwägbarkeiten bei den AMD-Karten zu viele (Kernel, Mesa, Backportorgie, aktuelle Fähigkeiten von amdgpu).
Nachdem ich nochmal die Dokumentation zu den Nvidia-Karten studiert habe, habe ich eine GTX 950 bestellt, denn die 2. Maxwell-Generation soll abgesehen von 8k die gleichen Decoder-Fähigkeiten haben wie Pascal.

[wanne]

Also die GTX 980 und GTX 960 können definitiv kein h.265.

Btw. der i7 war ein i7-5820K