Kaveri - der Trinity Nachfolger

Mir ist hald dieser "Video Converter" bekannt, den es schon ewig im Catalyst gibt:



In diesem Fall 13.1 auf einer HD4200 :) Bei meinen R9 280X mit 13.12 gibts das auch (noch). Neuere Treiber habe ich nicht installiert...

LG
Ich hab Handbreak noch installiert, weiß aber leider nicht mehr welche Version.
Beim 14.4 WHQL (2nd Edition) habe ich die Option auch:

 
Seltsam bei mir taucht der Eintrag nicht auf. Vielleicht liegt es an Win8.1

Catalyst.jpg

Ich probiere gerade etwas mit Handbreak rum. Ich mit Big Buck Bunny angefangen. Dort hat anscheint die Hardware Decodierung nicht funktioniert.

[18:23:29] libhb: scan thread found 1 valid title(s)
+ title 1:
+ stream: D:\big_buck_bunny_1080p_surround.avi
+ duration: 00:09:56
+ size: 1920x1080, pixel aspect: 1/1, display aspect: 1.78, 24.000 fps
+ autocrop: 0/0/0/0
+ support opencl: yes
+ support hwd: no

[18:23:29] job configuration:
[18:23:29] * source
[18:23:29] + D:\big_buck_bunny_1080p_surround.avi
[18:23:29] + container: avi
[18:23:29] + data rate: 12455 kbps
[18:23:29] + decoder: mpeg4
[18:23:29] + filters
[18:23:29] + Framerate Shaper (1:27000000:1125000)
[18:23:29] + frame rate: 24.000 fps -> constant 24.000 fps
[18:23:29] + Crop and Scale (1920:1080:0:0:0:0)
[18:23:29] + source: 1920 * 1080, crop (0/0/0/0): 1920 * 1080, scale: 1920 * 1080
[18:23:29] + loose anamorphic
[18:23:29] + encoder: H.264 (libx264)
[18:23:29] + tune: ,fastdecode
[18:23:29] + profile: high
[18:23:29] + level: 4.0
[18:23:29] + quality: 21.00 (RF)
[18:23:29] * audio track 1
[18:23:29] + decoder: Unknown (AC3) (5.1 ch) (track 1, id 0x1)
[18:23:29] + bitrate: 448 kbps, samplerate: 48000 Hz
[18:23:29] + AC3 Passthru
[18:23:29] reader: first SCR 0 id 0x1 DTS 0
[18:23:29] dxva2xFindVideoServiceConversion failed
[18:23:29] encx264: min-keyint: 24, keyint: 240
[18:23:29] encx264: encoding at constant RF 21.000000
[18:23:29] encx264: unparsed options: level=4.0:weightb=0:no-deblock=1:cabac=0:weightp=0:vbv-bufsize=31250:vbv-maxrate=25000
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
x264 [info]: profile High, level 4.0
[18:35:35] reader: done. 1 scr changes
[18:35:39] work: average encoding speed for job is 19.646463 fps
[18:35:39] sync: got 14315 frames, 14314 expected
[18:35:39] render: 14315 frames output, 0 dropped and 0 duped for CFR/PFR
[18:35:39] render: lost time: 0 (0 frames)
[18:35:39] render: gained time: 0 (0 frames) (0 not accounted for)
[18:35:39] mpeg4-decoder done: 14315 frames, 0 decoder errors, 0 drops
x264 [info]: frame I:154 Avg QP:14.23 size:255627
x264 [info]: frame P:10049 Avg QP:18.90 size: 35067
x264 [info]: frame B:4112 Avg QP:23.02 size: 7981
x264 [info]: consecutive B-frames: 59.4% 4.5% 7.3% 28.8%
x264 [info]: mb I I16..4: 24.8% 62.9% 12.3%
x264 [info]: mb P I16..4: 2.8% 3.9% 0.6% P16..4: 32.9% 9.2% 3.8% 0.0% 0.0% skip:46.9%
x264 [info]: mb B I16..4: 0.4% 0.9% 0.2% B16..8: 18.8% 2.2% 0.3% direct: 1.9% skip:75.3% L0:43.9% L1:44.5% BI:11.6%
x264 [info]: 8x8 transform intra:55.6% inter:63.1%
x264 [info]: coded y,uvDC,uvAC intra: 53.4% 59.9% 25.9% inter: 12.3% 18.9% 2.4%
x264 [info]: i16 v,h,dc,p: 51% 22% 9% 18%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 17% 26% 4% 5% 9% 5% 6% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 28% 16% 12% 5% 9% 11% 8% 7% 5%
x264 [info]: i8c dc,h,v,p: 51% 21% 20% 8%
x264 [info]: ref P L0: 86.0% 9.7% 4.3%
x264 [info]: ref B L0: 77.8% 19.9% 2.3%
x264 [info]: ref B L1: 94.9% 5.1%
x264 [info]: kb/s:5694.56
[18:35:39] ac3-decoder done: 0 frames, 0 decoder errors, 0 drops
[18:35:39] mux: track 0, 14315 frames, 424564596 bytes, 5694.47 kbps, fifo 1024
[18:35:39] mux: track 1, 18640 frames, 33402880 bytes, 448.02 kbps, fifo 2048
[18:35:39] libhb: work result = 0
Encode done!
HandBrake has exited.

Dann habe ich eine Aufnahme aus dem Fernsehn genommen, die ich vorher zurecht geschnitten habe. Wichtiger ist das bei diesem Film nun die Hardware Decodierung und open Cl funktioniert. Darüber hinaus taucht ein "Using Zero Copy" auf. Ist das nicht eine nur APU-Eigenschaft? Das Zero Copy gibt es nur bei open-Cl.

Input #0, matroska,webm, from 'D:\Filme\Ancient X-files\S1E01 Der Heilige Gral.mkv':
Metadata:
ENCODER : Lavf54.63.104
Duration: 00:43:20.04, start: 0.000000, bitrate: N/A
Stream #0.0: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 50 fps, 1k tbn, 100 tbc (default)
+ stream: D:\Filme\Ancient X-files\S1E01 Der Heilige Gral.mkv
+ duration: 00:43:20
+ size: 1280x720, pixel aspect: 1/1, display aspect: 1.78, 50.000 fps
+ autocrop: 0/2/0/0
+ support opencl: yes
+ support hwd: yes

[20:33:15] + container: Matroska (libavformat)
[20:33:15] * video track
[20:33:15] + decoder: h264
[20:33:15] + filters
[20:33:15] + Detelecine (pullup) (default settings)
[20:33:15] + Framerate Shaper (0:27000000:540000)
[20:33:15] + frame rate: same as source (around 50.000 fps)
[20:33:15] + Crop and Scale (1280:718:0:2:0:0)
[20:33:15] + source: 1280 * 720, crop (0/2/0/0): 1280 * 718, scale: 1280 * 718
[20:33:15] + loose anamorphic
[20:33:15] + storage dimensions: 1280 * 718, mod 2
[20:33:15] + pixel aspect ratio: 1 / 1
[20:33:15] + display dimensions: 1280 * 718
[20:33:15] + encoder: H.264 (libx264)
[20:33:15] + preset: fast
[20:33:15] + tune: ,fastdecode
[20:33:15] + profile: high
[20:33:15] + level: 4.0
[20:33:15] + quality: 20.00 (RF)
[20:33:15] * audio track 1
[20:33:15] + decoder: Deutsch (AC3) (2.0 ch) (track 4, id 0x4)
[20:33:15] + bitrate: 448 kbps, samplerate: 48000 Hz
[20:33:15] + AC3 Passthru
[20:33:15] reader: first SCR 9000 id 0x0 DTS 9000
[20:33:15] dxva2:CreateSurface succeed with 17, fmt (1280x720) surfaces (1280x720)
[20:33:15] dxva2:we got 2 decoder configurations
[20:33:15] dxva2:configuration[0] ConfigBitstreamRaw 2
[20:33:15] dxva2:configuration[1] ConfigBitstreamRaw 2
[20:33:15] dxva2:IDirectXVideoDecoderService_CreateVideoDecoder succeed
[20:33:15] dxva2:Using DXVA2 for hardware decoding
[20:33:15] encx264: min-keyint: 50, keyint: 500
[20:33:15] dxva2:Available decoder output format 61 (AV_PIX_FMT_DXVA2_VLD)
[20:33:15] encx264: encoding at constant RF 20.000000
[20:33:15] encx264: unparsed options: level=4.0:ref=2:weightb=0:no-deblock=1:cabac=0:weightp=0:subme=6:vbv-bufsize=31250:vbv-maxrate=25000:rc-lookahead=30
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
x264 [info]: profile High, level 4.0
[20:33:16] Scaling With OpenCL
[20:33:16] Using Zero Copy
[20:48:19] sync: adding 188 ms of silence to audio 0x4 start 54031320, next 54014400
[21:41:45] reader: done. 1 scr changes
[21:41:48] work: average encoding speed for job is 31.618038 fps

Die Log Dateien habe ich etwas gekürzt.
 
Zuletzt bearbeitet:
Auf Realworldtech gibt es einen kleinen Artikel zur Taktgenerierung der Steamroller Cores. http://www.realworldtech.com/steamroller-clocking/
Das "Adaptive Clocking" hilft demnach die Effizienz zu steigern indem bei starken Lastschwankungen der CPU die Taktrate gesenkt werden kann.
Klingt sehr interssant, wobei man damit auf die nominale Taktrate der CPU langsam nicht mehr viel geben kann. Die typisch eingesetzten Tools zum Auslesen der Taktrate bekommen von den schnellen Schwankungen vermutlich auch nicht viel mit.
Interssant ist auch, dass die Technik vor allem bei hohen Taktraten (Richtung 4 GHz) große Einsparpotenziale bieten soll. Gerade der Bereich in dem Kaveri paradoxerweise im Gegensatz zum Vorgänger am Wenigsten effizienter wurde, was vermutlich aber auch der Fertigung geschuldet ist.

Daneben hatte AMD ja auch schon integrierte Spannungsregler für künftige CPUs angekündigt, die letztendlich das gleiche Problem weiter optimieren dürften.
gruß tex_
 
Hat da jemand eine Ahnung, wie das jetzt (d.h. heute) ist mit dem GPU-x264 encoden? Ist das qualitativ ident mit dem Encoden mit der CPU? Läuft das (unten verlinkte Handbrake-Beispiel) über die VCE Einheit? Oder anders?

Handbrake.jpg


Quelle: http://blackholetec.com/drupal7/article/amd-a10-7850k-kaveri-review-page-7

LG
Nein, VCE kommt nicht zum Einsatz. Das läuft über OpenCL direkt auf den Shadern. Es gibt meines Wissens nach auch keine Wechselwirkung mit irgendwelchen Einstellungen im CCC.

Es handelt sich noch immer um die gleiche GPU-Beschleunigung von x.264, die ich in dem Artikel behandelt habe (kurz: die lookahead-Funktion wird auf der GPU berechnet), der in meiner Signatur verlinkt ist. Bei handbrake kommt noch hinzu, dass auch die Skalierung des Videos über die GPU realisiert wird.

Gerade mit der Skalierung gibt es erhebliche Probleme. Hier kann es zu erheblichen Abweichungen bei der finalen Bitrate der Transkodierten Videos kommen. Entsprechend ändert sich auch der Rechenaufwand beim Enkodieren. Meine letzten Tests haben da keine Vergleichbaren Ergebnisse zwischen reiner CPU-Berechnung und zusätzlicher Nutzung der GPU gezeigt. Die Ergebnisse (Bitrate und damit Dateigrößte) unterscheiden sich einfach zu sehr.


Der Zeit-Vorteil hängt stark davon ab, ob und wie stark die Skalierung des Videos ausfällt.
 
"Bald Eagle" (embedded Kaveri R-Serie) started.
Die Leistungsdaten entsprechen denen der Notebookchips.

Dh, AMD setzt nun darauf Embedded/Server vor den consumer Notebooks zu bringen.

Läuft das (unten verlinkte Handbrake-Beispiel) über die VCE Einheit? Oder anders?

Ne, das neue Media SDK wird soweit mir bekannt noch von keiner SW verwendet. Deshalb sind Mediaespreso benchs wertlos, da sie eingebaute Funktionen nicht nutzen bei AMD für Intel Quicksi* gab es sogar ein .x Release.
 
Zuletzt bearbeitet:
Naja, bald ist gut, so wie wir die PC Hersteller kennne kommen die erst im Oktober, wenn überhaupt.
Ich bleibe dabei Carrizo wird wohl die bessere Wahl sein, aber die kommt auch nicht früher in 2015, wird aber von anfang an HSA SW haben oder zumindest nach den 1.0 Versionen der HSA Tools komme. Wer nicht zwingend dieses Jahr eine APU braucht soll warten.
 
Nun glaubt man dieser Meldung von WCCFtech, so kommt der mobile Kaveri mit weiterentwickelten CPU-Cores.
http://wccftech.com/amd-mobile-kaveri-apu-confirmed-steamroller-excavator-hybrid-architectures/

Die Sprache ist von einer Steamroller-Excavator Hybrid Architektur.
Nur halte ich von der Quelle recht wenig und dort wird auch viel völliger Blödsinn verzapft. z.B.:
The flagship of the Mobile Kaveri Series is an OEM Only Product. The consumer products actually start from the A10-7400P and consists of a total of 7 APUs in descending orders of power.
Ich wüsste nicht welche mobilen APUs keine OEM Produkte wären und seit wann man mobile CPUs im Retail (comsumer) Markt kaufen kann.
 
Ist eine Fehlmeldung !

Die mobilen Kaveri haben die gleiche OPN-Endung (JA) was gleiches Stepping belegt.
AM7000ECH23JA
AM720PDGH44JA
AM740PDGH44JA
 
Zuletzt bearbeitet:
Hätte mich ehrlich gesagt auch gewundert, wenn es anders gewesen wäre. Die mobilen Modelle sind ja schon länger angekündigt. Kann sich demzufolge nur um den gleichen Entwicklungszyklus wie die Desktopmodelle handeln. Weiterentwickelte Kerne sollten nicht vor Carizzo frühestens Ende diesen / Anfang nächsten Jahres aufschlagen.
 
Notebook kommt ja bald, Computex steht vor der Tür.

Und selbst wenn Notebooks kommen sollte, werde ich auf alle Fälle keins kaufen da es bestimmt:

  • Mit Schminkspiegel
  • extra dick
  • extra schwer
  • Sinn freien Konfigurationen:
    • bspw. 6GB
    • dGPU welche langsamer oder kaum schneller ist als die iGPU
    • 3-4 Zellen Akku(?!)
  • bescheidener Verarbeitung
  • Minimalistischer Auflösung (1366x768)
  • (16:9 Seitenverhältnis statt 16:10)
  • Ohne SSD
  • Und ALLE WEITEREN die mir Spontan nicht einfallen
 
Und selbst wenn Notebooks kommen sollte, werde ich auf alle Fälle keins kaufen da es bestimmt:

  • Mit Schminkspiegel
  • extra dick
  • extra schwer
  • Sinn freien Konfigurationen:
    • bspw. 6GB
    • dGPU welche langsamer oder kaum schneller ist als die iGPU
    • 3-4 Zellen Akku(?!)
  • bescheidener Verarbeitung
  • Minimalistischer Auflösung (1366x768)
  • (16:9 Seitenverhältnis statt 16:10)
  • Ohne SSD
  • Und ALLE WEITEREN die mir Spontan nicht einfallen

+1

Da muss AMD wirklich tätig werden, damit diese hirnrissigen Konfigurationen unterlassen werden.
Reicht ja wenn Sie sagen, in den Konfigs muss man geeignete Kombis auswählen können.
Die vorkonfigs können ja gerne so hirnrissig bleiben.
 
Träum weiter. AMD hat keine Marktmacht und muss froh sein über jeden "Design Win". Deine Forderung bedeutet Zusatzkosten für die Gerätehersteller und macht das Produkt (die APUs) somit weniger attraktiv.
 
Träumen ist erlaubt. Von einem Markt, der brauchbare Produkte zu angemessenen Kosten hervorbringt.
MfG
 
Träum weiter. AMD hat keine Marktmacht und muss froh sein über jeden "Design Win". Deine Forderung bedeutet Zusatzkosten für die Gerätehersteller und macht das Produkt (die APUs) somit weniger attraktiv.

wieso soll der aufwand steigen? wenn dann sinkt er eher, da man ja einfach mal das model welches sie für intel designed haben übernehmen könnte ;)

das schlechte macht einem mehr arbeit, den dieses muss man entwerfen. das gute ist schon da.
 
Worns: Korrekt ;)

~DeD~: Mehr Varianten -> mehr SKUs (Geräte mit einmaligen Eigenschaften, eigenem Produktcode) -> höhere Lagerkosten. Und höherer Aufwand an mehreren Stellen. Auch wenn die Varianten (andres Display für das selbe Chassis) eigentlich schon existieren.
 
Nein, VCE kommt nicht zum Einsatz. Das läuft über OpenCL direkt auf den Shadern. Es gibt meines Wissens nach auch keine Wechselwirkung mit irgendwelchen Einstellungen im CCC.

Es handelt sich noch immer um die gleiche GPU-Beschleunigung von x.264, die ich in dem Artikel behandelt habe (kurz: die lookahead-Funktion wird auf der GPU berechnet), der in meiner Signatur verlinkt ist. Bei handbrake kommt noch hinzu, dass auch die Skalierung des Videos über die GPU realisiert wird.

Gerade mit der Skalierung gibt es erhebliche Probleme. Hier kann es zu erheblichen Abweichungen bei der finalen Bitrate der Transkodierten Videos kommen. Entsprechend ändert sich auch der Rechenaufwand beim Enkodieren. Meine letzten Tests haben da keine Vergleichbaren Ergebnisse zwischen reiner CPU-Berechnung und zusätzlicher Nutzung der GPU gezeigt. Die Ergebnisse (Bitrate und damit Dateigrößte) unterscheiden sich einfach zu sehr.


Der Zeit-Vorteil hängt stark davon ab, ob und wie stark die Skalierung des Videos ausfällt.

Einer aus dem Computerbase Forum hat nachgefragt und das war im Prinzip auch deren Antwort.
http://www.computerbase.de/forum/showthread.php?t=1347220&p=15739787#post15739787
 
Moin ich hab beim stöbern im Aldi Prospekt tatsächlich ein weiteres Kaveri - Deskop Modell gefunden, den A10-7800. Wenn das Namensschema halbwegs konsistent ist ist das der Nachfolger des A10-6700. Allgemein scheint der Pc für 399€ ein fairer Deal zu sein. Unten dann der Link.

aldi-nord.de/aldi_multimedia_pc_system_48_5_1768_24055.html?wt_mc=de.intern.StdTwoCarousel.welcome.on-ma&wt_cc1=1_1&wt_cc3=MD%208349
 
Zuletzt bearbeitet:
Tolle Nachricht, Ioner! Dann geht es ja endlich voran mit Kaveri im Desktop! Das Angebot ist sicher ganz OK für Leute, die partout nicht schrauben oder aufrüsten werden. Eine SSD müsste im Jahr 2014 aber schon noch rein!

Besser natürlich etwas warten und selber bauen: mit Windows 7 (!), SSD, Standard-Komponenten (kein ALDI-Spezial-Mainboard), und hochwertigeren Komponenten. Dafür etwas teurer.
 
Zuletzt bearbeitet:
Hab ich nur das dumpfe Gefühl, dass in dem Medion nur ein RAM Riegel steckt? 2GB 1866er Riegel dürften vermutlich nicht all zu viele hergestellt werden.

Das Angebot ist aber denke ich dennoch fair, ist ja auch noch Windows (auch wenn es das 8er ist) dabei. Beim selber bauen würde ich wohl 500€ investieren, dann aber mit SSD+HDD und 8GB RAM
 
Lenovo hält doch die Mehrheit an Medion. Ob da noch mehr von Lenovo mit Kaveri kommt?
 
Ich habe hier noch ein paar interessante Details zu HSA in Kaveri gefunden. Ich weiss allerdings nicht ob diese Folien schon irgendwo aufgetaucht sind, soweit ich weiss nicht.

slide-7-1024.jpg


Interessant hier wie die Aufgabenverteilung bei der Videocodierung ist und wo Energieeffizienz in welchem Maße verbessert werden kann.

Auf der folgenden Folie sind auch die Datenpfade in Hardware mal übersichtlich dargestellt und auch in welchem Szenario welche Datenpfade genutzt werden:

slide-10-1024.jpg


Hier sollten vor allem diejenigen mal einen Blick drauf werfen, die immer wieder einen Level3 Cache für die APUs fordern ;)

Interessant auch für die Gaming Fraktion wo HSA in Spielen Vorteile bietet und in welchem Umfang. Die meisten sehen ja nur Physik als Einsatzgebiet:

slide-24-1024.jpg


"Frustum Culling"
slide-25-1024.jpg


"Occlusion Culling"
slide-26-1024.jpg


Sortieren - bisher durch den Kopieroverhaead für GPGPU nicht sinnvoll nutzbar.
slide-27-1024.jpg


Dekompression durch die iGPU ohne CPU und dGPU Last.
slide-28-1024.jpg


Pathfinding (KI)
slide-29-1024.jpg


Nur um auch mal zu zeigen, dass durchaus alle Arten von Spielen von HSA profitieren können. Manche vielleicht mehr und manche weniger, doch hier ist deutlich mehr als nur KI oder CPU Entlastung möglich!
 
Zuletzt bearbeitet:
Zurück
Oben Unten