News AMD Carrizo: Deutlich effizienter und etwas schneller

[Jesterfox]

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!

Der größte Teil der Konsolen APUs sind die Grafikeinheiten die eh schon optimiert sind und zumindest im Golem-Artikel wird erwähnt das auch bei den Puma-Cores das ganze schon zum Einsatz kommt. Die Chips der Konsolen wären somit schon im reduzierten Design.

 

[Piktogramm]

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.

Wenn du der Meinung bist, dass meine Aussagen nicht stimmen, dann halte doch bitte mit irgendwas dagegen, was entsprechend an dieser Stelle aufzeigt, dass ich falsch liege. Ein "mimimi du hast keine Ahnung weil ich das sage" ist nicht sonderlich überzeugend .
Könnte ich genauso machen, wäre aber lächerlich jemanden Wissen abzusprechen, wenn die Differenzen hauptsächlich aus der unterschiedlichen Bewertung der Wirksamkeit von technischen Maßnahmen liegt.

 

[Daedal]

Dazu gibt es hier genügend HSA-Threads die bald ein Jahr alt sind wo ich einiges an Material dazu zusammen getragen habe. einfach im Forum die Suche mit "HSA" füttern. Diese Diskussionen habe ich nun schon 10 mal mindestens durch. Und jedesmal sind es 3 -5 Seiten nur weil die grundlegenden Dinge missverstanden wurden. Das von mir zitierte kannst du im HSA Whitepaper, welches du ja selber schon erwähnt hast als eine Quelle die du nutzt, nach lesen.

Wahrscheinlich das erste Whtiepaper das zu einem "Abfall" von OpenCL gemacht wurde. Nur ist OpenCL lediglich eine von vielen HSA-fähigen Sprachen und APIs. Vor allem solltest du dir den Teil mit Compiler und ISA Übersetzung durchlesen um mal zu begreifen über welche technische Eben wir hier diskutieren. HSA ist keine Sprache, keine API und auch keine Exklusive AMD Erfindung. HSA beschreibt das heterogene Computing. Dazu gehören AES Einheiten, UVD, VCE, GPU und CPU-Kerne, ebenso wie ein h.256 Decoder oder sonstige programmierbare Compute Einheiten.

Überdenke anhand diese Info den Ansatz deines vorherigen "abfälligen" Beitrags.

Edit - einige Quellen:
http://developer.amd.com/wordpress/media/2013/06/2620_final.pdf
https://github.com/HSAFoundation/HS...tations,-Drivers,-Compilers,-Tools,-Libraries
https://github.com/HSAFoundation/HSA-docs-AMD/wiki
http://www.planet3dnow.de/vbulletin/showthread.php/414730-Alles-ueber-um-HSA-aus-dem-Kabinithread
http://www.planet3dnow.de/vbulletin...Kabinithread?p=4945131&viewfull=1#post4945131

 

[Piktogramm]

@Deadal

Der Erkenntnisgewinn ist gering
Klar HSA ist ein in der Theorie gutes Mittel um CPU, GPU und sonstige Hardwarebeschleuniger besser zusammen zu nutzen. Nur ist für mich noch immer fraglich, ob der Aufwand den Gewinn rechtfertigt.

Wenn man sich die Benchmarks anschaut, überall wo LibreOffice dran steht geh ich nicht mehr drauf ein. Wie gesagt, der HSA fähige OpenCL Teil verrechnet sich und schnelles falsch rechnen ist schlicht wertlos.

Beim HSA Jpeg Decoding fehlt zum einen ein Test, ob die Anzeige über das HSA binary wirklich zum Softwaredecoding gleichwertige Ergenisse führt (hier kann man wie beim Encoding auch bedingt Geschwindigkeit gegen Qualität eintauschen). Auch frage ich mich, hätte das HSA binary evtl. auch ein nicht HSA fähiges System beschleunigt?

Beo Corel fehlt genauso eine Validierung, ob das Ergebnis mit dem HSA fähigem Binary identische Ergebnisse liefert (hier sei einfach mal auf die Hardwareencoder von AMD, Nvidia und Intel verwiesen. Die sind extrem schnell, die Qualität ist aber (vor allem bei AMD) recht mau).


Wie gesagt ich bin da skeptisch und solang da Binaries vom Hersteller kommen deren Ergebnisse von den Testern nicht validiert werden hebt mich das nicht an. Da gehe ich davon aus, dass der Hersteller für die eigenen Produkte fröhlich optimiert und für andere eben dies unterlässt.

 

[Daedal]

Deine Skepsis ist irrelevant und auch HSA für diesen Thread. Daher vertiefe deine Erkenntnisse doch in den verlinkten Themen wo es um HSA geht und teile deine Thesen den dort interessierten mit.

 

[[F]L4SH]

Wo hast du deine zweierlei Maß eigentlich gekauft Piktogramm? Ich finde immer nur diese blöden normierten Maße

Ich will auch feststellen können, dass AVX bei Haswell total viel gebracht hat und generell toll ist aber AMD das ganz bestimmt nicht erreichen können wird und HSA total blöd, nicht das fortschrittlichste am Markt und nicht sehr sinnvoll ist (Quick Sync ist aber total toll!!!!)

 

[Piktogramm]

@[F]L4SH:

Das zweierlei Maß entsteht großteils anscheinend bei den Lesern .

AVX2 hat bei Haswell viel gebracht weil die APUs und FPUs über die Tick/Tock Zyklen daraufhin angepasst wurden und ich bezweifle, dass es bei AMD im Bereich der Floatingpointoperationen die selben relativen Zuwachs wie bei Haswell geben wird. Wobei ich meine Vermutung damit begründet habe, dass die FPUs der aktuellen AMD CPUs einfach nicht all zu leistungsfähig sind und es kurz vor Zen unwahrscheinlich ist, die FPUs entsprechend umfangreich zu überarbeiten. Wobei die FPUs nicht dadurch leistungsfähiger werden, dass neue Befehle unterstützt werden. Bei Zen erwarte ich dafür größere Sprünge, nur um Zen geht es noch nicht .
Entsprechend sind da nicht zwei Maße, sondern eine sehr einfache Abschätzung aufgrund bekannter Sachverhalte. Inwieweit die Integerleistung die von AVX2 auch berührt wird skalieren wird, dazu erlaube ich mir keine Aussage.


Zudem habe ich auch an keiner Stelle HSA so verdammt wie du es mir in die Schuhe schieben willst (und soooo übel verklausuliert schreibe ich nicht). Ich gestehe HSA als solches in der Theorie ein hohes Potential zu, jedoch mit klaren Einschränkungen in der Praxis. Derzeit ist es einfach vergleichsweise viel Aufwand HSA Funktionalität zu nutzen, das ganze funktioniert einfach derzeit nicht ohne gezielt daraufhin zu arbeiten und läuft im PC nur auf einer sehr kleinen Anzahl an Systemen und auf Servern eigentlich überhaupt nicht (schlicht und ergreifend weil AMD in der Sparte keine attraktiven Angebote hat).
Wobei die meisten durchaus real vorhanden Demos zu HSA in Form von Benchmarks oftmals methodische Fehler aufweisen.

Das QuickSync total toll ist habe ich nicht geschrieben. Ich habe die div. Hardwareencoder für Videos als Vergleich herangezogen. Eben weil diese Videoencoder zwar verflixt schnell sind (lässt sich mit Benchmarks entsprechend nachweisen), diese Geschwindigkeit bei den meisten Umsetzungen jedoch eine schlechtere Qualität als Softwareencoder bei selber Bitrate liefern oder aber für eine gleiche Qualität eine höhere Bitrate benötigen. Ich hoffe du stimmst mir zu, dass unter dieser Vorraussetzung ein Vergleich der reinen Geschwindigkeit beim Encoding sinnlos ist, da das Ergebnis nicht gleichwertig ist. Diese Betrachtung sparen sich viele OpenCL/HSA Benchmarks jedoch komplett. Da wird gebencht ohne nachvollziehbare Kontrolle, ob diese Benchmarks überhaupt als Vergleich taugen.

Wenn wir schon dabei sind, eine Sache an der Intel arbeitet und die Bestandteil von HSA ist, ist ZeroCopy (nur ohne den HSA "Rattenschwanz"). Bei Intel schaut es so aus, als wäre dies nutzbar ohne zusätzlichen Aufwand zu betreiben. Damit kann man diesen Vorteil nahezu komplett mitnehmen indem man übliche Compiler nutzt. Der zusätzliche Aufwand beim Entwickeln ist also nahezu 0. An der Stelle kann man also ohne Mehraufwand für eine weit verbreitete Hardwareplattform entwickeln -> sinnvoll

So und damit der Post nicht mit "pro Intel" endet und das nicht wieder falsch verstanden werden kann. Klar HSA als Abstrationsschicht um die Funktionalität hardwareübergreifend zwischen x86, ARM und im Zweifelsfall noch anderen ist total klasse. Super Ansatz, gute Idee, in dieser Beziehung besser als Intels Insellösung!

 

[jodd]

Und jedesmal sind es 3 -5 Seiten nur weil die ....


Und das wird es diesmal nicht, sonst ist hier zu.