News AMD Carrizo: Deutlich effizienter und etwas schneller

Ich rede hier ja nicht zwangsweise von betriebswirtschaftlicher Attraktivität, sondern von technischer. Davon mal ab ist es nur eine Frage der Zeit bis auch Intel mit seinen APUs nachzieht und OpenCL 2.0 supported.
 
YforU schrieb:
Das ist nicht korrekt.

notebookcheck

Falsch,
Und deren Test dazu sag ich mal Weniger:

A10 Trinity: Damals 1. Test von Ihnen,
Igp nur auf dem Niveau einer HD4000

Nach 2 Tagen kam raus das die Pappenheimer 1066er Singlechannel Nachträglich verbaut haben.
-------------------------------------------------------------------------------------------------------------

Genau so wenig kommt,
Mein Netbook mit dem Quad Celeron @ 2,16 auf die Werte die sie angeblich bei dem Tablet mit 1,35-1,8 erreichen


NBC ist Intel versessen Hoch 10
:rolleyes:
 
Zuletzt bearbeitet:
@sdwaroc

Auch technisch ist es so eine Sache. In der Theorie sieht das HSA Konzept gut aus, die frage ist wie verhält es sich real. Da gibt es wenig (nichts) konkretes aus halbwegs unabhänigen Quellen.
 
Also in wissenschaftlichen arbeiten gibt es schon ein bisschen was dazu und auch im Bereich des RayTracings gibt es einige Ergebnisse.

Die Samples der AMD APP SDK bietet auch ein paar HSA Benchmarks vs. herkömmliche Implementierung an. Der Quellcode ist einsehbar daher kann man daraus schon ganz gut Rückschlüsse auf die Leistungsfähigkeit ziehen.
 
ja aber es ist extrem Anwendungsfall bezogen... oftmals bringt es 0 bis gar nichts, oder verkompliziert die Sache nur. Bei grafischen Dingen wie RayTracing, welch Wunder, skalieren hoch-skalare Architekturen ähnlich einer GPU extrem gut.
Pixel lassen sich eben sehr gut parallelisiert berechnen. Genau deswegen gibt es Grafikkarten auch erst überhaupt.

"HSA" oder welchen Namen man dafür auch immer vergeben mag ist sicher super, aber eben nur dann wenn sich der Aufwand auch lohnt und am Strich mehr bei rumkommt. Viele granulare Aufgaben lassen sich aber kaum parallelisieren (genau deswegen gibts CPU Kerne die immer mehr auf Pro Thread Leistung getrimmt wurden, Turbo usw).
 
Gerade mal meinen A10-7350B mit Maximaltakt dagegen gebencht (warum hält 3DMark den für einen 7850K?), der sieht mal so gar kein Land gegen den Carrizo. Die Tatsache an sich kommt wenig überraschend, das Ausmaß aber schon.
 
sdwaroc schrieb:
3D Grafik ist nur eine der vielen Anwendungsgebiete des Raytracings...

natürlich, aber so gut wie jedes Raytracing Project lässt sich extrem gut parallelisieren und dadurch prädestiniert durch GPU Computing beschleunigt zu werden - was ja auch gut ist. HSA / GPU Computing ist in meinen Augen keine wirkliche Revolution - im Grunde sind wir durch das Aufblasen von Kernen und deren Beschränkung durch den Takt (~4Ghz) was die eigentliche CPU Kern Entwicklung angeht langsam am Limit (sehr geringe IPC Fortschritte), ein Endverbraucher hat wenig von 15 Kernen, ergo entwickelt man sich an anderen Stellen weiter. Ähnlich einem weiteren Befehlssatz entwickelt sich die GPU hin zum fixen CPU Bestandsteil für diese hochparallelisierbaren Aufgaben im Consumerbereich, neben FPU, Integer Einheit usw..

Wichtig ist dass diese Einheit für den Entwickler irgendwann vollkommen transparent angesprochen wird - was ja HSA usw als Ziel hat.
 
Piktogramm schrieb:
@sdwaroc

Auch technisch ist es so eine Sache. In der Theorie sieht das HSA Konzept gut aus, die frage ist wie verhält es sich real. Da gibt es wenig (nichts) konkretes aus halbwegs unabhänigen Quellen.
Corel Aftershots und LibreOffice sind nur zwei Beispiele wo HSA enorme Leistungssteigerungen zeigt. HSA ist schon längst angekommen. Ist aber wirklich seltsam, dass immer noch manche meinen da gäbe es nichts.
 
Mit Corel kenn ich mich nicht aus, da bin ich still aber LibreOffice ist ein eher schlechtes Beispiel :)

Stand LibreOffice 4.2 ist OpenCL ab Werk deaktiviert und das aus gutem Grund. Da gibt es so lustige Fehlerchen, dass If-Statements unter "bestimmten Bedingungen"* immer True zurück geben, es werden nur elementare Operationen** unterstützt etc. pp.
Unter diesen Bedingungen muss man sagen, dass diese OpenCL Umsetzung klar als Beta zu bezeichnen ist (ein riesen +50MB spreadschead und eine Engine die sich mitunter verrechnet, hossa!)
Die Benchmarks sind ansonsten alle recht mau. Zum einen stammen die Beispieldaten meist von AMD, mann muss also davon ausgehen dass da ein Spreadsheet verteilt wird, welches ausschließlich Funktionen enthält die OpenCL beschleunigt werden, was den optimalen Fall darstellt dessen Praxisrelevanz bezweifelt werden darf. Genauso sind die ganzen Benchmakrks meist nur Intel CPU vs AMD GPU. Da gewinnt die AMD GPU dann auch mit Abstand. Wobei hier einige die Schuld auf Intel schieben (Treiber) und andere anmerken, dass der Inteltreiber schlickt geblockt wird ohne Angabe von Gründen (nicht vergessen, der OpenCL Teil in LibreOffice kommt großteils von AMD!). Wobei der Vergleich der OpenCL Leistung unter Photoshop (Blur-Filter) bei einem i3/i5 mit der einer Kaveri APU vergleichbar ist*** (ich bin jemand der bei unter 10% Abweichung die Schulter zuckt). Hier ist also auch fraglich, wie andere Systeme ohne HSA aber mit OpenCL Unterstützung skalieren würden, wenn sie denn nutzbar wären.
Es ist damit bewiesen, GPU Beschleunigung kann an einigen Stellen etwas bringen (Überraschung), der Mehrwert von HSA ist aber so eine Sache, da fehlen einfach vergleichbare Werte von Systemen die HSA eben nicht haben.



*ich liebe derart ins Detail gehende Dokumentationen von Bugs
**leider lässt sich die Dokumentation hier auch nicht aus, verweist nur, dass man die betreffenden Teule des Programms selber auseiander nehmen darf... Das muss früh 6Uhr aber nicht sein :D
***Also während LibreOffice Intels Treiber blockt wenn es um OpenCL geht reicht die Treiberqualität für Adobe aus?! Erscheint mit fischig.
 
Zuletzt bearbeitet:
Na zumindest sind wir mal 2 Jahre vorwärts gesprungen in der Zeit. Aus "gibt es nirgendwo" ist eine schlechte Implementierung geworden bei einzelnen Projekten. Jedes Mantle Spiel nutzt HSA-Techniken, es ist darin enthalten. Dazu gibt es auch hier im Forum entsprechende Themen wo das mit Quellen belegt ist. Diese Diskussion ist aber auch schon Monate alt und eigentlich beendet da HSA in einigen Programmen zum Einsatz kommt.
 
Stand LibreOffice 4.2 ist OpenCL ab Werk deaktiviert und das aus gutem Grund. Da gibt es so lustige Fehlerchen, dass If-Statements unter "bestimmten Bedingungen"* immer True zurück geben, es werden nur elementare Operationen** unterstützt etc. pp.

Das ist aber mit Sicherheit nicht OpenGL sondern ein schlechter Programmierer bei Libre...

Unter diesen Bedingungen muss man sagen, dass diese OpenCL Umsetzung klar als Beta zu bezeichnen ist (ein riesen +50MB spreadschead und eine Engine die sich mitunter verrechnet, hossa!)

Lästerst du gerade über die umfassende Dokumentation? Und ja, der Spreadsheat ist riesig, steht ja auch alles von OpenCL 1.0 bis 2.0 drauf, inklusive mehrerer Memory-Modelle und Strukturen.

Und OpenCL, um das nochmal ganz deutlich gesagt zu haben, ist kein AMD-Projekt. Die Spezifikationen werden nicht von AMD gemacht (übrigens genau wie bei OpenCL).

Hier ist also auch fraglich, wie andere Systeme ohne HSA aber mit OpenCL Unterstützung skalieren würden, wenn sie denn nutzbar wären.

Das kann ich dir sagen: Ohne HSA frisst der Cverhead beim hin- und rückkopieren die Leistungssteigerung durch die GPU auf.

Es ist damit bewiesen, GPU Beschleunigung kann an einigen Stellen etwas bringen (Überraschung), der Mehrwert von HSA ist aber so eine Sache, da fehlen einfach vergleichbare Werte von Systemen die HSA eben nicht haben.

Bewiesen ist mit deinem Absatz da gar nichts, maximal hast du etwas dargelegt (aus deinem sehr individuellen Standpunkt heraus).

Es ist damit bewiesen, GPU Beschleunigung kann an einigen Stellen etwas bringen (Überraschung), der Mehrwert von HSA ist aber so eine Sache, da fehlen einfach vergleichbare Werte von Systemen die HSA eben nicht haben.

Dann musst du aber wieder CPUs gegen APUs bzw. SOCs antreten lassen und das gefiel dir ja weiter oben schon nicht. Es jst schlicht nicht möglich OpenCL 1.2 wie 2.0 zu nutzen. Alles was du für HSA, also im Programm dann VSM schreibst ist auf nicht-HSA-Maschnen nicht lauffähig. und die Aufgaben die durch 2.0 praktisch zu beschleunigen sind können so gut beschleunigt werden, weil jetzt in ein und den selben spreicher geschrieben wird und selbst Pointer erhalten bleiben.
 
Leider wirds wohl wieder so kommen wie die letzten Jahre auch. Die NB Hersteller werden die APUs kaum bis gar nicht verbauen und somit wird der geneigte Kunde sich mal wieder nur halbgaren Kram oder eben ein Intel NB zulegen müssen.

Ich wollte seinerzeit auch ein "Richland" Gerät, aber es gab nichts. So wurde es dann eines mit "Trinity" APU.

Dabei klingen 40% weniger Leistungsaufnahme echt gut.
 
@Deadal

Mantel ist zwar ohne Frage gut, viele der Kniffe die Mantle umsetzt gehen aber auch ohne HSA wunderbar. Siehe die Nvidia Treiber die ganz gut aufgeholt haben und DirectX12 welches unter Nvidia (und wahrscheinlich auch Intel) entsprechend besser läuft als die DirectX11 Implementationen die es vor Mantle gab.
Auch hier ist fraglich, wie groß der Gewinn durch HSA zu beziffern ist und wie groß die anderen Einflussfaktoren sind. Bringt HSA im Vergleich zu den anderen Maßnahmen ist es nicht Attraktiv für HSA zu entwickeln da Niesche.


@sdwaroc

Ich habe nicht geschrieben das OpenCL dran schuld sei (und schon gar nicht OpenGL wie du es schreibst :) ). Was jedoch beachtet werden sollte, die OpenCL Umsetzung inkl HSA Funktionalität wurde von AMD beigesteuert. Diesen Schuh kann man den Entwicklern von LibreOffice nicht sorecht in die Schuhe schieben ;)

Mit dem 50MB Spreadscheet meinte ich (wieso habe ich eigentlich "Spreadshead" geschrieben, was für ein Stuss!) die typisch großen Tabellen, die von OpenCL am deutlichsten profitieren (je größer desto besser) und dass es bei einer so großen Tabelle, die von Menschen kaum mehr kontrollierbar ist, nicht akzeptabel ist mit einer Softwareumsetzung zu arbeiten die da im Zweifelsfall Fehler einbringt. Der Geschwindigkeitszuwachs bringt nichts, wenn das Ergebnis nicht stimmt (langsame Software die richtig arbeitet ist akzeptabel, schnelle Software die Fehler produziert ist es nicht!).
Über die Dokumentation habe ich wirklich gelästert, aber an anderer Stelle. Ne Dokumentation die besagt "Software rechnet fehlerhaft, wir verraten aber nicht unter welchen Bedingungen" ist einfach Käse! Genauso wie die fehlende Dokumentation welche Operationen wirklich in OpenCL umgesetzt wurden.

Ob der Overhead beim Kopieren wirklich all zu schlimm ausfällt hängt stark von der Umsetzung ab. Wenn für jede Teiloperation und jeden Zugriff auf eine Zelle des Dokumentes ein Speicherzugriff resultiert bringt direkter Speicherzugriff durch die GPU entsprechend viel. Wenn der ganze Spaß so umgesetzt wird, dass die Daten in einem Schwung kopiert werden ist der Overhead jedoch vergleichsweise klein und damit die Vorteile von HSA ebenfalls minimiert. Wie überall muss man da genauer hinsehen, bevor man wirklich halbwegs fundierte Aussagen treffen kann.

Mit den erwähnten Benchmarks kann man sehr wohl zeigen, dass sich Anwendungen mittels Nutzung von GPU-Computing mittels OpenCL beschleunigen lässt. Es lässt sich aber der Einfluss von HSA meist nicht auf diese Art und Weise beweisen. Der Letzte teil ist eine Aussage meinerseits und an keiner Stelle als Beweis verkauft. Bitte lies nicht Dinge in Texte hinein die nicht da sind ;)

Gegen Vergleiche zwischen CPUs gegen APUs, gegen SoCs habe ich doch garnix gesagt. Wenn muss die Vergleichsbasis stimmen, was oft jedoch nicht passt. Wenn man nachweisen will, dass HSA etwas bringt müsste entsprechend die GPU einer APU einmal mit und ohne HSA Funktionalität vergleichen werden um den Effekt von HSA nachweisen zu können. Wobei an der Stelle wie bereits erwähnt die Umsetzung der Software auch eine entscheidende Rolle hat. Mit Software die Speicherzugriffe minimiert verliert HSA auch an Einfluss (wobei das minimieren von Speicherzugriffen generell angebracht ist, die Speicheranbindung ist schon für moderne CPUs ohne GPU ein Flaschenhals). Wenn man CPUs und SoCs die kein HSA können sollte man denen bei solchen Vergleichen auch erlauben auf der selben Basis zu aggieren, solang sie technisch dazu in der Lage sind. Daher, wenn eine APU ihre GPU nutzen darf sollte das eine andere CPU mit iGPU oder ein SoC genauso tun dürfen. Vergleiche wo eine APU ihre iGPU nutzen darf und aus technisch nicht nachvollziehbaren Gründen die vergleichs CPU den OpenCL Code über die CPU laufen lassen muss sind einfach sinnlos. Bei nem Pferderennen wo bis auf einen alle die Hufe zusammengebunden bekommen kann ich dir das Ergebnis noch vor Beginn des Rennens verraten -.-
 
Morrich schrieb:
Leider wirds wohl wieder so kommen wie die letzten Jahre auch. Die NB Hersteller werden die APUs kaum bis gar nicht verbauen und somit wird der geneigte Kunde sich mal wieder nur halbgaren Kram oder eben ein Intel NB zulegen müssen.

Wenn AMD ein gutes Produkt liefert wird das auch verbaut. Beispiel: Beema
Notebooks (inkl. Varianten) auf Geizhals

Mit AMD Beema SoCs: 156
Mit AMD Beema bzw. Kabini SoCs: 240
Mit Intel Bay Trail-M SoCs: 326

Das Kaveri mit 63 zu 2599 (Haswell) Listungen in Relation derart katastrophal abschneidet liegt daran das diese APU weiter in einer Linie mit Trinity und Richland steht. Funktioniert erst bei einer TDP oberhalb von 30W ordentlich und braucht zusätzlich eine vergleichsweise fette FCH auf dem PCB. Mainstream Notebooks sind heute im Regelfall für eine TDP von 15W konzipiert und für das Segment darüber sind die Kaveri APUs eher uninteressant da vergleichsweise langsam.

AMD kann im mobilen Markt praktisch nur Produkte unterbringen welche zu Intels Plattform Designrichtlinien (Gehäuse und Kühlung) kompatibel sind. Kaveri ist das im Gegensatz zu Beema höchstens eingeschränkt. Aufgrund der Marktverteilung und des höheren Risikos dürfte es ziemlich unmöglich sein OEMs für die dedizierte Entwicklung von AMD Notebook Designs ohne Subventionierung zu motivieren. Carrizo zielt deshalb auf 15W TDP ab und hat den gleichen PCB Footprint wie Beema. Passt damit in das gleiche Format wie Broadwell-U.
 
Zuletzt bearbeitet:
Piktogramm schrieb:
@Deadal

Mantel ist zwar ohne Frage gut, viele der Kniffe die Mantle umsetzt gehen aber auch ohne HSA wunderbar. Siehe die Nvidia Treiber die ganz gut aufgeholt haben und DirectX12 welches unter Nvidia (und wahrscheinlich auch Intel) entsprechend besser läuft als die DirectX11 Implementationen die es vor Mantle gab.
Auch hier ist fraglich, wie groß der Gewinn durch HSA zu beziffern ist und wie groß die anderen Einflussfaktoren sind. Bringt HSA im Vergleich zu den anderen Maßnahmen ist es nicht Attraktiv für HSA zu entwickeln da Niesche.
Na das ist doch gut. Aus "HSA Anwendungen gibt es nicht" sind wir über "Sind ja alles nur einzelne Programme und Beta" angekommen bei der tatsächlich aktuellen Frage wo HSA der Vorreiter ist, dass weitflächig heterogenes Computing Einzug hält. Wir sind mittendrin und hier kannst du auch eine umfangreiche Liste der Programme finden die sich heterogener Techniken bedienen:
http://developer.amd.com/community/application-showcase/
Und immer daran denken, dass HSA mehr ist als CPU+GPU Computing. Jede Fixed Function Unit kann bei HSA unterstützend die CPU entlasten und die Anwendung beschleunigen.

DX12 kann übrigens nicht auf HSA aufholen, sondern DX12 bedient sich HSA-Techniken um zu Mantle aufzuschließen. Oder konnte DX11 irgendwie zu x86 aufholen?
 
Piktogramm schrieb:
Stand LibreOffice 4.2

Wen interessiert den das vorletzte Release einer Software? Aktuell ist 4.4, und du scheinst mir ziemlich voreingenommen gegenüber AMD zu sein, inkl. der Anschuldigung, AMD hätte Intel benachteiligt. Die Rollenverteilung ist klassischerweise umgekehrt, was auch schon gerichtlich bewiesen wurde, nur leider immer viel zu spät ;-)
 
@Deadal:

Die Änderung die du von meiner Haltung zeichnest gibt es nur in deinem Wunschdenken :).
Das was du da als umfangreiche Liste bezeichnest sind sehr wenige Programme, deren HSA Funktionalität mehr oder weniger zufällig daher kommt, dass die OpenCL /Direct Compute einsetzen und es sind großteils Nischenanwendungen. Wirklich direkt auf HSA Kompatiblität ist dort wahrscheinlich auch nix getrimmt, da der Spaß wohl gleichermaßen auf jeder Hardware laufen können wird die OpenCL/Direct Compute unterstützt. Directer HSA Bezug ist nur bedingt vorhanden, eher ist die Möglichkeit HSA Funktionalität zu nutzen eher "Abfall" dessen, dass eh mit OpenCL programmiert wurde, direkt Entwickelt um HSA nutzen zu können wird man da kaum haben.
In Post #77 wurde sogar behauptet, dass die FPUs in der CPU nahezu egal sind, da die Rechenleistung für Floatingpoint durch die GPU erbraucht werden kann. Was aber schlicht nicht stimmt, dass funktioniert derzeit nur, wenn man speziell für GPU-Computing entwickelt, was wiederum nur sinnvoll ist, wenn sich das Problem ausreichend parallelisieren lässt. Hier arbeitet der ganze Spaß eben nicht so universal wie es Post #77 gern hätte, sondern es gibt recht klare Bedingungen wann die Rechenleistung der GPU sinnvoll eingesetzt werden kann.

Genauso HSA und Mantle / DirectX12, AMD selbst erwähnt HSA im ganzen Whitepaper für Mante mit keinem Wort Herterogene Architekturen (HSA), nichtmal Verweise gibt es. Viel mehr ist es "nur" eine deutlich entschlackte und an aktuelle Mehrkernprozessoren angepasste API, ohne direkte Abhänigkeit zu einer Herterogenen Systemarchitektur.

Damit bleibt der HSA Spaß für mich aktuell und in absehbarer Zukunft ein Nischenprodukt eines Nischenherstellers für das es sich kaum lohnt direkt zu entwickeln.
Die Theoretischen Vorteile von HSA sind ansonsten wirklich toll. Die Praxis ist nur eine andere Sache.


@HaZweiOh

Die Dokumentation von LibreOffice und OpenCL war bei 4.2 einfach recht ordentlich und wenn ich es nicht komplett überlesen habe ist es bis zu 4.4 nicht viel besser geworden (zumindest in den Releasenotes zu 4.4 steht NICHTS zu "OpenCL", "GPU", "HSA", "Hetero"). Entsprechend stützte ich mich einfach auf Software in einer Version wo es Dokumentation gibt. Wobei mit 4.2 der Stand herrschte: Nicht nutzbar, da Rechenfehler auftreten zu 4.4: wir verlieren kein Sterbenswort mehr zur Sache.

Ich bin voreingenommen gegenüber AMD, Intel, Nvidia und Co. Ich erwarte von allen Herstellern (auch außerhalb der IT), dass sie wenn es um ihre eigene Produkte geht diese im best möglichen Licht dastehen lassen. Was im Endeffekt meist heißt, dass perfekt aufs Produkt zugeschnittene Leistungsvergleiche durchgeführt werden oder gar beschissen wird. Da nehmen die sich alle nichts!



Ansonsten versteht mich nicht falsch, ich würde mich tierisch freuen, wenn AMD zu Potte kommen würde!
Jedoch ist HSA kein Heilsbringer. HSA kann Vorteile bringen, für sich genommen sind die aber nicht so bedeutend, als dass damit die enormen Schwächen an anderer Stelle kompensiert werden können. Vor allem weil gleichzeitig die Konkurrenz nicht schläft.
 
Wenn die Module so extrem geschrumpft sind, wundert mich, dass AMD da nicht doch etwas für den Profimarkt bringt. Immerhin gehört denen einer der größten Hersteller für Mikroserver (was immer noch ein kleiner Hersteller ist aber nunja) und gerade in solchen Bereichen oder auch in Supercomputern könnte man damit doch gut wildern. Wenn man nun meinetwegen 10 Module auf einem Chip unterbringt, kommt da selbst bei nur 1,5Ghz eine enorme Leistung zusammen. Wenn der Preis dann noch stimmt...

Vielleicht kommt ja noch mal ein HD-Redesign der Konsolen APUs. Wenn die Chipfläche da auch entsprechend sinkt, werden MS und Sony sehr daran interessiert sein - zumal die Chips ja noch locker für 6 Jahre in der Produktion sein werden und momentan wirklich -verdammt- groß sind!
 
Piktogramm schrieb:
. Directer HSA Bezug ist nur bedingt vorhanden, eher ist die Möglichkeit HSA Funktionalität zu nutzen eher "Abfall" dessen, dass eh mit OpenCL programmiert wurde, direkt Entwickelt um HSA nutzen zu können wird man da kaum haben.
Ich hab jetzt nur mal den Teil zitiert der dich völlig disqualifiziert zu dem Thema Äusserungen zu machen.

Beschäftige dich mit den Grundlagen und ich schlage vor du liest erstmal nach was HSA ist. Der Rest den du dazuschreibst ist auch entsprechend nicht haltbar.
 
Zurück
Oben