Artikel AMD A10-7700K und A10-7850K im Test

[Complicated]

Warum? Weil CPU Transistoren und GPU Transistoren völlig andere Leistungswerte auf ihren spezifischen dedizierten Chips haben. GPU ist deutlich dichter gepackt und CPU ist für deutlich höhere Taktraten ausgelegt. Führt man diese auf einen Die und verwendet die selbe Fertigung, dann sind sehr viele Abstriche zu machen, das erfährt doch Intel ebenso und haben es nicht selber hin bekommen Performante iGPUs mit CPUs zu verschmelzen. Daher kaufen sie Nvidia Technologie ein..

--- Update ---

Dir fehlen Basiswissen und lesen scheinst auch nicht deine Stärke zu sein. Ich frage mich was dich dazu qualifiziert erprobte und exklusive Technologie von AMD als Marketing zu bezeichnen, wenn trollen nicht deine Absicht ist.

 

[SPINA]

GPU ist deutlich dichter gepackt und CPU ist für deutlich höhere Taktraten ausgelegt.

Die Integration in einen Chip, war bereits unter dem 1. Punkt abgehandelt, also wird "common" hier nicht "gemeinsam" sondern "verbreitet" bedeuten. Soviel zum Leseverständnis. Und es sind durchaus exotischere Fertigungstechnologien denkbar als "3x/2x/1xnm bulk".

Die Schwierigkeiten mit der unterschiedlichen Packungsdichte und der erforderlichen Schaltgeschwindigkeit ergeben sich gleichfalls innerhalb eines x86 Kernes. Damit haben sich Intel und AMD schon seit Jahrzehnten herumzuschlagen. So stellt zum Beispiel ein L2-Cache gänzlich andere Anforderungen als die FPU. Deswegen verwendet man unterschiedliche Transistordesigns innerhalb desselben Chips. Und man erreicht infolge dessen lediglich an auserwählten Stellen die kleinste Strukturgröße, die die Fertigung ermöglicht. Viele Einheiten sind mit mehr Atomlagen und dadurch gröber ausgelegt, als es der Prozess erlaubt. Eine iGPU verkompliziert die Angelegenheit natürlich weiter, aber die Herausforderung ist dennoch keine gänzlich Neue. Man denke zum Beispiel an den Pentium 4. Dort liefen die ALUs mit der doppelten Frequenz des Grundtaktes. Es wurden folglich bis zu 7600 MHz innerhalb des Chips erreicht und das vor über 10 Jahren. Das ging nur, weil Intel bei der Fertigung tief in die Trickkiste gegriffen hat. Ein Chipdesign erfordert stets einige Kompromisse. So zu tun, als wäre das vor der Einführund der APUs anders gewesen, ist irreführend. Schon vorher waren zahlreiche Klimmzüge erforderlich. Eine CPU - ob mit oder ohne iGPU - ist nun einmal ein stark heterogenes Gefüge. Beinah jede Baugruppe hat von der Benachbarten abweichende Anforderungen.

Daher kaufen sie Nvidia Technologie ein..

Da du es immer wieder in den Raum stellst, hätte ich jetzt von dir gern eine vollständige Übersicht welche nVidia Technologien Intel konkret in seinen Produkten an welcher Stelle nutzt. Sollte dies nicht gelingen, höre bitte damit auf, dich darauf zu versteifen.

PS: HSA in dem derzeitigen Zustand als "qualifiziert erprobte" Technologie zu bezeichen ist reichlich verwegen. Bisher wurde uns allenfalls ein kleiner Vorgeschmack gegeben. AMD hat noch einen langen, steinigen Weg vor sich. Insbesondere an der Software, allen voran den Compilern, muss noch gefeilt werden. HSA muss zur Zeit als "unfertig" bezeichnet werden. Ich bin jedoch mehr als zuversichtlich, dass AMD dieses Mal am Ball bleibt.

 

[Complicated]

Also weshalb muss ICH jetzt eine Liste aller lizenzierten Technologie aufführen die Intel von Nvidia nutzt?
Dazu ist wohl keiner imstande, der nicht dort im Vorstand die Verträge ausgehandelt hat. Und eine Quelle dafür dass diese Technologie lizenziert wurde habe ich jetzt mehrfach gepostet. Du kannst ja gerne weiter auf Ignorant machen, doch lass mich dabei raus.

Schmeisst mir hier drei Wörter ohne Kontext hin und meinst ich muss dann erahnen aus welcher Quelle du das hast. Soviel zur Bedeutung von "common" und sinnlosem vom Thema abweichendem Geplänkel. Und deine Interpretation, dass es sich dabei um den Gebrauch "verbreitet" handelt entspricht ja nicht der Realität die darauf folgte. Die Fertigung war AMD APU Exklusiv und ist es ja bis heute beim Kaveri. Aber sehr wohl war Llano in dieser ersten Stufe der erste der gemeinsame Fertigung für CPU und GPU enthielt. Nun bau dir deine Welt halt weiter so wie du sie gerne hättest, aber lass doch die anderen in der Realität leben.

Und HSA ist mittlerweile in der dritten Iteration auf dem Markt. Es gibt auch kein fertiges Endprodukt das sich dann HSA nennt, da die Weiterentwicklung nicht stehen bleibt. HSA umfasst Hardware, Compiler, APIs, Software und Treiber, sprich ist eine SYSTEM ARCHITEKTUR die sich HETEROGENER (unterschiedlicher) Prozessoren bedient, die integriert sind oder auch zu geschaltet werden können über Steckplätze in der nächsten Generation laut Roadmap.

Das wäre als ob du sagen würdest die Pentium 3 sind keine x86-Architektur. Das musst du endlich begreifen.

 

[heikosch]

Ich mische mich auch nochmal ein:

Complicated, vermische bitte nicht die Begriffe "Heterogeneous Computing" und "Heterogeneous System Architecture". Das Zusammenwirken von Prozessoren aller Art würde ich unter ersterem Punkt führen. Markant für die Systemarchitektur ist jedoch der gemeinsame Adressraum. Diese Möglichkeit besteht erst seit der Einführung von Kaveri und ist aktuell ja noch nicht einmal wirklich nutzbar. Leider muss man da anscheinend sagen, dass AMD wieder ein Feature für die Kunden geliefert hat, das aktuell keiner so richtig nutzen kann. Die VCE kommt gefühlt auch jetzt erst richtig in Fahrt.

Um die Systemarchitektur zu verbreiten, muss ich deshalb SPINA zustimmen, ist man von einer hohen Verbreitung abhängig. Was bringt Dir die beste Technik, wenn sie keiner nutzen kann?! Seitens der Software fehlt da momentan eine gehörige Ecke, wie ich finde.

 

[sompe]

Ähm....ich bin mir gerade nicht sicher ob es überhaupt sinnvoll ist zwischen der Verbreitung und der Integration zu unterscheiden denn letztendlich findet beides beim ersten Punkt statt. Wie kann man etwas verbreiten was es nicht gibt?
Es ist auch normal das die Hardware vor der Software kommt, vor allem im CPU Bereich oder wann habt ihr das letzte mal erlebt das ein Feature seitens der Software vor der Hardware auf den Markt kam?

Irgendwie ist die ganze Diskussion in meinen Augen sinnlos...

 

[Gast11062015]

a10 7850k, 7700k oder a8 7600
oder doch einen 6790K


schwierig schwierig das ganze

 

[Complicated]

Um die Systemarchitektur zu verbreiten, muss ich deshalb SPINA zustimmen, ist man von einer hohen Verbreitung abhängig. Was bringt Dir die beste Technik, wenn sie keiner nutzen kann?! Seitens der Software fehlt da momentan eine gehörige Ecke, wie ich finde.

Das ist exakt was ich widerlegen möchte. Ihr rechnet Verbreitung in Software die nutzbar ist. Ich zeige euch Roadmaps die belegen, dass HSA wesentlich umfangreicher ist und in verschiedenen Ausbaustufen seit Llano schon genutzt wird. Zu behaupten die Technik werde erst benutzt wenn hUMA vorhanden ist ist falsch. Das ist lediglich Verbesserungen. Die einen fallen deutlicher spürbarer aus und die anderen weniger. Doch AMDs Herzstück bei HSA ist die IOMMUUv2 Einheit und die Virtualisierungsfunktionen die verschieden HSA Agenten anbinden können.

Ich zitiere mich mal selber fast 100 Beiträge zuvor:

Ich habe das mal hier thematisch im HSA Thread zusammengefasst:
http://www.planet3dnow.de/vbulletin...SA-aus-dem-Kabinithread?p=4945131#post4945131
Der wurde ja seit einem Jahr nicht mehr aktualisiert. Schau dir vor allem Corels Umsetzung an, da dort ganz konkrete Implementationen und Codebeispiele vorhanden sind.

Du hast von mir eine Riesenliste mit Hardware beschleunigter Software bekommen und schreibst hier immer noch über Relevanz einer Technik die schon längst benutzt wird. Mantle bei BF4 und Thief? Auch HSA Features vorhanden.

Wieviel Software kennst du die folgendes nutzt:

• Quicksync
• SSE4
• AVX
• AVX2
• AES

Da fragt sich komischerweise keiner nach der Relevanz. Da wird nur gefragt Wann kommt es endlich und 2 Wochen später machen alle so als ob es weit verbreitet und Standard ist. Wie viel Software gibt es, die auf dem Desktop dem User damit Vorteile bringt?

 

[SPINA]

Zu behaupten die Technik werde erst benutzt wenn hUMA vorhanden ist ist falsch. Das ist lediglich Verbesserungen.

Demnach ebenso die "neuartige" Pappe der PIB Verpackung; wusste ich es doch.

AMD würde sich ein Gefallen tun, wenn sie nur die Kernkomponenten unter den HSA Begriff fallen lassen. Sachfremde Dinge verwässern nur unnötig den HSA Begriff. Die Fertigung der Chips hat - wie oben angeführt - rein gar nichts mit der Funktionsweise von HSA zu tun. Man könnte genauso gut x86/ARM Kerne getrennt von den (C++ programmierbaren) Shader Units auf verschiedenen Dice belichten und sie per HyperTransport oder PCI Express kopplen. Solange sie einen gemeinsamen Adressraum haben und vorzugsweise zusätzlich denselben Memory Controller teilen, spräche nichts dagegen sie ebenfalls HSA zuzurechnen. AMD möchte den HSA Begriff schließlich nicht ausschließlich auf die eigenen Produkte gemünzt, sondern allgemein gebraucht, wissen. HSA ist außerdem wie bereits erörtert wurde ein Gesamtpaket. Es nützt nichts Teilaspekte zu betrachten. Das ist wie bei einem Getriebe. Nur wenn alle Zahnräder ineinander greifen, erfüllt es seinen Zweck. Praktisch nutzbar ist HSA dadurch erst in Ansätzen. Die Zukunft muss zeigen wozu HSA in der Lage ist. Noch gibt es zuviele Baustellen. Ich verstehe nicht, wie gerade du als AMD Fanboy, HSA so ins Triviale zerrst, indem du jeden "Mist" dazuzählst, Complicated.

HSA ist etwas Großes; keine banale Anhäufung von Marginalitäten.

 

[Complicated]

Demnach ebenso die "neuartige" Pappe der PIB Verpackung; wusste ich es doch.

Und das ist jetzt kein Trollen? Auf der Roadmap war keine Pappe verzeichnet. Was du betreibst nennt sich Übertreibung und wird so definiert:
http://de.wikipedia.org/wiki/Typen_von_Argumenten#.C3.9Cbertreibung

Mit dem Argumentum ad consequentiam wird aus einer richtigen Schlussfolgerung, aus deren Wahrheit der Aussage unangenehme oder scheinbar unerträgliche Konsequenzen folgen würden, die Falschheit, Unwichtigkeit oder Belanglosigkeit der Aussage durch Übertreibung unterstellt, um den Gegner lächerlich zu machen.

Was ich geschrieben habe ist korrekt. Du kannst dich damit befassen und auf den selben Wissenstand kommen oder es sein lassen. Hier weiterhin im Kreis zu drehen wird deine Scheinargumente nicht richtiger machen oder relevanter.

Auch die Bezeichnung als Fanboy soll dem dienen, verstehe ich. Doch ich halte mich einfach an AMDs veröffentlichten Definitionen die du ja auch gelesen hast. Und auch wenn du meinst wie AMD das anders definieren sollte, so bleibt es deine Definition und nicht die von AMD.

Alle haben alles falsch gemacht. AMD falsch definiert. Ich habe das auch noch idiotischerweise wörtlich genommen und muss jetzt eine Jahresdauerkarte im AMD Fanblock kaufen. Und du hast als einziger den Durchblick. Warum ist die Welt denn nur nicht so wie du sie gerne richtig definiert hättest. Noch nicht mal die Pappe ist HSA.

Edit: Du siehst auch ich kenne das Stilmittel der Übertreibung. Nur verwende ich es ungern, weil dabei nie etwas Konstruktives heraus kommt, da es keinerlei Argument zu irgendetwas enthält. Das war hier lediglich als Spiegel gedacht.

 

[WindHund]

Ich mische mich auch nochmal ein:

Complicated, vermische bitte nicht die Begriffe "Heterogeneous Computing" und "Heterogeneous System Architecture". Das Zusammenwirken von Prozessoren aller Art würde ich unter ersterem Punkt führen. Markant für die Systemarchitektur ist jedoch der gemeinsame Adressraum. Diese Möglichkeit besteht erst seit der Einführung von Kaveri und ist aktuell ja noch nicht einmal wirklich nutzbar. Leider muss man da anscheinend sagen, dass AMD wieder ein Feature für die Kunden geliefert hat, das aktuell keiner so richtig nutzen kann. Die VCE kommt gefühlt auch jetzt erst richtig in Fahrt.

Um die Systemarchitektur zu verbreiten, muss ich deshalb SPINA zustimmen, ist man von einer hohen Verbreitung abhängig. Was bringt Dir die beste Technik, wenn sie keiner nutzen kann?! Seitens der Software fehlt da momentan eine gehörige Ecke, wie ich finde.

Lässt sich bei einer APU mittels GPUz Sensoren nicht die Speicher Belegung (in MByte) auslesen?
Da sollte es "dedicated" und "dynamic" geben, so ist das bei mir seit ich CrossfireX nutze...
Gemeinsam=dynamic

 

[SPINA]

@WindHund: Handelt es sich bei dem "Dynamic"-Wert nicht um den (seit AGP) per DiME genutzen Hauptspeicher des Systems?

Stichwort: Aperture. Daraus lassen sich leider keine Rückschlüsse auf HSA ziehen. "Dedicated" bezeichnet den lokalen VRAM.

 

[WindHund]

@WindHund: Handelt es sich bei dem "Dynamic"-Wert nicht um den (seit AGP) per DiME genutzen Hauptspeicher des Systems?

Stichwort: Aperture. Daraus lassen sich leider keine Rückschlüsse auf HSA ziehen. "Dedicated" bezeichnet den lokalen VRAM.

Ok, das DiME höre ich zum ersten mal, leider keine Ahnung worauf du anspielst.
Der dynamische Speicher hat nichts mit CrossfireX zu tun, der ist auch mit nur einer GPU im System vorhanden bei GPUz.
Das interessante mit CrossfireX verdoppelt sich der vorhanden VRAM einer GPU (bei mir 3+3GByte).
Also beim spielen wird auch die doppelte Speichermenge belegt. (z.B. eine GPU=1.5GB, zwei GPUs=3GB)
3D Rendere nutzen den dynamischen Speicher inzwischen ebenfalls.

Bin gespannt ob sich genug Latenz sparen lässt, um nicht ins Speicherbandbreiten Limit zu rutschen. (APU)

 

[Solidus]

Um nochmal auf den ursprünglichen Testbericht zurückzukommen... ich sehe nirgends, ob irgendwo die VCE-Einheit gebencht wurde. Ich habe gestern mal das Openencodevfw installiert. Auch wenn Nvidia und Intel besser sein sollen - aber das ist ja mal richtig geiler Scheiß. Wenn man mal damit gearbeitet hat, ist es unverzichtbar, insbesondere ist die Leistungsaufnahme beim Encoden mit +8 W lächerlich.

 

[Complicated]

Auf dieser Seite sind noch ein paar Benchmarks, die auch die verwendete Software einbeziehen. z.B. sieht man ein völlig anderes Bild bei der Performance abhängig davon ob man Photoshop CC oder Musemage benutzt für die selben arbeiten (Photofilter in diesem Fall)
Aber nicht alles ist sinnvoll. Der Speichertest z.B. da bin ich mir nicht sicher was da überhaupt gemessen wird, da Kaveri ja einiges gar nicht mehr durch das Speicherinterface schicken muss, und dann die Transferraten automatisch niedriger sind bei der selben Aufgabe

Aber mal eine andere Auswahl an Software und eine sehr interessante Aufarbeitung bei der Strommessung, besonders die per Task Darstellung. Das würde ich gerne mal mit verschiedener Software sehen. Auch bei den Spieletest finde ich wesentlich mehr interessante Infos als nur die FPS.
http://techreport.com/review/25908/amd-a8-7600-kaveri-processor-reviewed/10

 

[Unbekannter Krieger]

@Solidus
Verstehe ich recht, dass du mit diesem Openencodevfw x264-Encoding per Grafikeinheit einer APU betrieben hast? Wie sahen die Ergebnisvideos aus?
Kann man das auch mit dGPUs tun, wenn ja nur mit GCN oder auch mit HD-6000ern?

 

[Solidus]

@Solidus
Verstehe ich recht, dass du mit diesem Openencodevfw x264-Encoding per Grafikeinheit einer APU betrieben hast? Wie sahen die Ergebnisvideos aus?

Exakt. Auf einem A10 7850K mit VideoPad. Nach der Installation von Opencodevfw (kann den Link nicht posten, ist aber über Google leicht zu finden) kann man unter den Ausgabeoptionen den Hardware-Encoder auswählen. Das Tempo (gefühlt ca. 50 % schneller als die CPU) hat mich jetzt nicht vom Hocker gerissen, dafür gab es ein Problem mit der Audiospur, das ich erst noch aussortieren musste. Aber wenn einem CPUID beim Encoden einen "Package"-Verbrauch von 30 W anzeigt (die iGPU läuft auf 1028 MHz) kann man echt nicht meckern.
Die Qualität scheint bei niedrigen Bitraten besser zu sein. Habe noch keine großen Testreihen gemacht, wollte erst mal nur den Film fertig schneiden. Die Qualität ist mir normal auch nicht so wichtig, weil's eh nur auf Youtube landet.
Nur mal als Vergleich: Wenn ich mit Trinity (5800K) auf der CPU encode, muss ich den Turbo deaktivieren, sonst habe ich nach 2 Minuten eine Notabschaltung.

Kann man das auch mit dGPUs tun, wenn ja nur mit GCN oder auch mit HD-6000ern?

Nach der Dokumentation nur auf CGN, da die anderen kein VCE haben:

VCE 1.0 Radeon HD 7900 series/Radeon R9 280X dGPU First release: AVC – I,P and DEM
Radeon HD 7800 series dGPU
Radeon R9 270X/270 dGPU
Radeon HD 7700 series/Radeon R7 250X dGPU
A10 – 58XX (and other variations) APU
A10 – 68XX APU

VCE 2.0 Radeon R9 290x/290 dGPU SVC (temporal) + B-pictures + DEM improvements
Radeon R7 260X/260 dGPU
A10 – 7850K APU
A4-5350, A4-3850, or E1-2650 APU
A4-1200/A6-1450 APU

 

[drSeehas]

...
Nach der Dokumentation nur auf CGN, ...

Soll wohl GCN heißen.
Es gibt aber auch einen GCN-Chip ohne VCE: Oland.

...
A10 – 58XX (and other variations) APU
A10 – 68XX APU

Trinity und Richland APUs sind aber VLIW4 und nicht GCN.

... A4-5350, A4-3850, or E1-2650 APU ...

Was soll denn das sein?
Gemeint sind wohl die Athlons und Semprons mit Sockel AM1.

 

[Solidus]

Hab gestern Abend noch ein wenig rumgespielt und die Zeit gestoppt.
2 Minuten Film zu rendern dauert 4 Minuten, das sind ca. 15 fps, also arg, arg mager und außerdem langsamer als die CPU. Hatte AMD nicht 60 fps versprochen?
Was bleibt, ist die Leistungsaufnahme. Die lässt sich zwar nicht zuverlässig auslesen, aber die Temperatur bleibt im Keller.

 

[Complicated]

Hmmm das wundert mich. Die VCE-Einheit ist ja in der Lage FullHD-Videos mittels ingame recording mit minimaler CPU Last in 60fps zu erstellen. Das ganze als mp4 mit H264 Codec mit 50 Mbit/s Bitrate: Hands On With AMD’s Gaming Evolved Client Game DVR

Welches Format hat denn deine Videoquelle und welches dein Endergebnis?

 

[Atombossler]

Hab gestern Abend noch ein wenig rumgespielt und die Zeit gestoppt.
2 Minuten Film zu rendern dauert 4 Minuten, das sind ca. 15 fps, also arg, arg mager und außerdem langsamer als die CPU. Hatte AMD nicht 60 fps versprochen?
Was bleibt, ist die Leistungsaufnahme. Die lässt sich zwar nicht zuverlässig auslesen, aber die Temperatur bleibt im Keller.

Na toll, da war ja mein alter PhII-X6 schon schneller und qualitativ hat es bisher noch keine GPU Lösung mit x264 @CPU aufnehmen können.
Hab aber keine Hardware um das vergleichen zu können, nur 5xxx GraKas.

 

[Casi030]

Wie schnell ist er den bei 3GHz?

 

[Dr@]

Der 64 Bit Mode von den Benchmark liefert defekte Videos und ist damit nicht repräsentativ.

--- Update ---

Ich komme schlicht drauf, weil ich die Messungen nicht nachstellen konnte.

Ich muss mal suchen, ob ich noch die Originalversion von den LibreOffice files finde. Da gab es letztens ne überarbeitete Version. Jendenfalls haben meine Werte überhaupt nicht zu jenen Erkenntnissen gepasst, die beispielsweise golem damals präsentiert hat. Ich kann auch nirgends zwischen OpenCL mit und ohne HSA umschalten. Letzlich installiere ich irgendeinen Treiber und soll mich dann darauf verlassen, dass da dann schon irgendwie was mit HSA drin ist und nicht nur normale Optimierungen an der Laufzeitumgebung.

Zudem ist OpenCL in LibreOffice noch immer nicht stabil. Es ist weiterhin ein experimentelles Feature, was vom nutzer explizit aktiviert werden muss. Auch hier ist somit die Relevanz äußerst fragwürdig. Die Vergangenheit hat mich gelehrt, hier vorsichtig zu sein. Leistungszuwächse in Betaversionen können wie von Geisterhand verschwinden, sobald alle Bugs gefunden sind.



Fragen zu diesen ganzen HSA Dingen wurden mir auch nicht wirklich beantwortet. Sämtliche Aussagen zu HSA bleiben vage. Somit bin ich bis auf weiteres sehr skeptisch.

Habe die alte Version von dem LibreOffice-Benchmark (AMD nennt es LOdemo1v7) noch bei mir auf der Platte gefunden, die damals zum Kaveri-Launch von AMD bereitgestellt wurde. Schneller Gegentest mit aktuellem Catalyst 14.8 WQHL - der nachweislich keinerlei HSA-Bestandteile enthält. Ich habe abermals anhand der Anleitung die korrekten Einstellungen in LibreOffice (verwende diejenige Version von LibreOffice 4.3 Beta 2, welche AMD mit dem Benchmark bereitstellt und die damit auch damals von Golem mutmaßlich verwendet wurde) überprüft. Zum Start der 65-W-Modelle gab es zwei aktualisierte Versionen LOdemo1-V13-1500rows und LOdemo1-V13-3000rows. In den zugehörigen Reviewer Guides spricht AMD auch nur von OpenCL-Beschleunigung. Von HSA ist da keine Rede.

Testsystem (privater Rechner):
A10-7850K @ Standardeinstellungen
Asus A88X-Pro (BIOS 1301 vom 24.06.2014)
2x 8 GiB DDR3-2133
Win 8.1 64 Bit (Energiesparplan: Ausbalanciert)

Nachdem die Verwendung von OpenCL in LibreOffice (experimentelles Feature, auch in der aktuellen stabilen Version) über das Optionen-Menü aktiviert wurde, gibt es die Möglichkeit, entweder LibreOffice die zu verwendende OpenCL-Hardware wählen zu lassen oder diese manuell aus einer Liste selber auszuwählen. Nachfolgend sind die bestehenden Auswahlmöglichkeiten (in fett) samt der zugehörigen Messwerte aufgelistet:

Software:
laut Anzeige etwas schneller als 2,5 s. Belastet wird nur ein CPU-Kern.
Diese Einstellung dürfte dem normalen Berechnungsmodus entsprechen, der standardmäßig auch in LibreOffice 4.3 verwendet wird. Das Officepaket kann ja (ohne OpenCL) nur einen CPU-Kern verwenden. Mein Gegentest mit deaktiviertem OpenCL liefert entsprechend auch das gleiche Ergebnis.

AMD Accelerated Parallel Processing Spectre (Frequency: 720, Compute Units: 8, Memory (in MB): 3071):
laut Anzeige erfolgt die Aktualisierung alle ca. 0,3 bis 0,33 s
Es wird OpenCL (Spectre ist der OpenCL-Name der GPU von Kaveri) verwendet, um die Berechnungen auf die GPU zu verlagern. GPU-z zeigt mir eine schlechte Auslastung der GPU an. Es springt ständig zwischen 0 und 95 % (Extremwerte). Eine gleichmäßige Last wird nicht erzeugt.
Die CPU-Auslastung durch LiberOffice liegt stets bei ca. 25 % - es wird also nur ein CPU-Kern verwendet.

AMD Accelerated Parallel Processing AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G (Frequency: 3700, Compute Units: 4, Memory (in MB): 2048 ):
laut Anzeige erfolgt die aktualisierung alle ca. 2.2 s.
Hier wird offensichtlich schlicht OpenCL auf den CPU-Kernen verwendet um so LibreOffice mehrer CPU-Kerne gleichzeitig nutzen zu lassen. Die CPU-Auslastung von LibreOffice schwankt zwischen 76 und 86 %. Es werden offenbar alle vier CPU-Kerne der APU verwndet.

Zum Vergleich laut Golem mit A8-7600:
Software: 2,6 s
OpenCL: 2,2 s
HSA: 0,6 s
http://www.golem.de/news/test-amd-kaveri-a8-7600-die-45-watt-wohnzimmer-apu-1401-103846-3.html

Was Golem unter OpenCL und was unter HSA versteht, weiß ich nicht. Diese Auswahlmöglichkeiten stellt LibreOffice nicht zur Verfügung. Die dortigen Namen habe ich oben verwendet.


Mag sein, dass die A10 APU etwas mehr Rohleistung hat. Die Ergebnisse liegen aber so dicht beieinander, dass ich weiterhin nicht an eine Verwendung von HSA (sei es direkt der HSA Software Stack oder eine HSA beschleunigte OpenCL-Laufzeitumgebung.) glauben kann - zumal meine OpenCL-Werte nahezu doppelt so schnell wie jene HSA-Werte von Golem sind. Bin gerade am überlegen, ob es sich noch lohnt, den damaligen Catalyst mit HSA-Komponennte (was auch immer die genau für Kaveri bewirkt) noch zu installieren. Eigentlich habe ich keine Lust, weil ich keinerlei neue Erkenntnisse erwarte.



Wenn Interesse besteht, kann ich die entsprechenden LibreOffice files samt Anleitung gerne bereitstellen.

 

[Complicated]

Na offensichtlich OpenCL auf CPU und HSA. Wenn HSA möglich ist, wird OpenCL automatisch auf CPU/GPU verteilt. Das zeigen ja auch deine Beschreibungen der CPU und GPU Last in dem Szenario. Kannst du in dem Test auch Stromverbrauch messen?

Was das Treiberszenario angeht bin ich sowieso nicht sicher derzeit. Bei manchem hat man den Eindruck sind keine speziellen HSA Treiber nötig, da auf Hardwareebene teilweise Code und Speicher balanciert wird, während offensichtlich API/Treiber Optimierungen noch zusätzlich Performance oder in einigen Szenarien überhaupt erst Steigerungen möglich machen.
Das wäre aber auch nicht verwunderlich, da ja auf beiden Ebenen unterschiedliche Workloads passend sind die Hardwareseitig oder Softwareseitig oder von beiden profitieren.

 

[Casi030]

Ich hab jetzt einfach nur die neuste Version 4.3 von der Seite runter geladen,brauch ich sonst noch was?

--- Update ---

OK,die Testdatei fehlt.......

 

[Dr@]

Na offensichtlich OpenCL auf CPU und HSA. Wenn HSA möglich ist, wird OpenCL automatisch auf CPU/GPU verteilt. Das zeigen ja auch deine Beschreibungen der CPU und GPU Last in dem Szenario. Kannst du in dem Test auch Stromverbrauch messen?

Was das Treiberszenario angeht bin ich sowieso nicht sicher derzeit. Bei manchem hat man den Eindruck sind keine speziellen HSA Treiber nötig, da auf Hardwareebene teilweise Code und Speicher balanciert wird, während offensichtlich API/Treiber Optimierungen noch zusätzlich Performance oder in einigen Szenarien überhaupt erst Steigerungen möglich machen.
Das wäre aber auch nicht verwunderlich, da ja auf beiden Ebenen unterschiedliche Workloads passend sind die Hardwareseitig oder Softwareseitig oder von beiden profitieren.

Es kommt kein HSA zum Einsatz, weil schlicht kein HSA im aktuellen von mir genutzten Treiber enthalten ist.

Für den AfterShot HSA Test gab es einen speziellen Treiber mit HSA Stack. Der benötigt aber eine spezielle Anleitung für die Installation. In den normalen Catalyst Paketen (nur jene für die APUs, nicht im normalen Catalyst) war auch mal was HSA mäßiges enthalten, was aber inzwischen ja wieder verschwunden ist. Wo da jetzt der Unterschied liegt, kann ich nicht richtig sagen.

Meinen damaligen Gegentest hatte ich mit einem jener Treiber durchgeführt wo die HSA Komponennte unbekannter Funktionalität enthalten war. Das Ergebnis war aus der Erinnerung heraus im Prinzip das gleiche.


--- Update ---

Ich hab jetzt einfach nur die neuste Version 4.3 von der Seite runter geladen,brauch ich sonst noch was?

--- Update ---

OK,die Testdatei fehlt.......

Ich lade es mal hoch. Mom. Kann etwas dauern.