News Carrizo: Neue AMD-APU zeigt sich in Benchmarks

Daedal schrieb:

PACS, PAX... Du hast Recht die Software heisst PACS. Die Großrechner welche die Daten des Panels umrechnen werden haben häufig den Namen PAX (und auch so geschrieben). War trotzdem mein Fehler ändert aber nichts daran, dass in diesen Rechnern weder Matrox noch AMD steckt. Sondern Intel und nVidia (in Form von Teslas).
Die Befundungsrechner erledigen eben NICHT den Großteil der Rechenarbeit.

Daedal schrieb:
Das glaube ich eher nicht. Da er sonst wüsste, dass Intel für die sogenannten "Befundrechner" gar keine ausreichend hoch auflösende GPU anbietet um hier irgendetwas zu dominieren. Hier ist Matrox in der Bildgebenden Diagnose deutlich besser aufgestellt als Nvidia. Siehe auch Krethis Link. Der Marktführer für COM (Computer-on-Modules) verbaut hier AMD embedded Produkte weil sie genau diese Eigenschaften vereinen. Nvidia Technik haben die gar nicht im Portfolio soweit ich weis.

Die Auflösung ist nur eine Sache die Graustufen eine andere (wenn wir schon bei der Radiologie sind). Ich habe auch nie gesagt, dass Intel in diesem Bereich irgendwas zu sagen hat. Ein Befundungsrechner unterliegt aber üblicher Weise nicht der EN 60601-1. Das kann, bis auf die Grafikkarte (aus oben genannten Gründen), im Prinzip auch ein normaler Rechner sein.
Vielleicht sollte hier mal unterschieden werden zwischen Rechnern, die nur im medizinschen Umfeld eingesetzt werden (und daher eigentlich nichts mit medizinischen Normen zu tun haben) und Rechnern, die mit medizinischen Geräten verbunden werden.
Das Congatec AMD verbaut heisst erst mal nichts. Das tut Fujitsu auch. Das heisst nur leider überhaupt nicht, dass die Teile auch im medizinishen Umfeld eingesetzt werden. Das kann prinzipiell (!! Details spare ich mir) nämlich erst mal jedes Mainboard - da hätte ich auch nen Link zu irgendeinem Gigabyte Mainboard posten können. Interessant sind hier die Einsatzwecke und die verkauften Stückzahlen - und da dürfte es dünn aus sehen.
Dennoch ist der eKabini im embedded Bereich relativ (!!) erfolgreich. Das kann man von den anderen AMD Produkten aber nicht behaupten.
Matrox hatten wir schon - in diesem Bereich mehr oder weniger reine Bildwiedergabe. KEINE Bildbearbeitung.

Daedal schrieb:
Und sollte sich jemand wundern was in der Medizin "PaX-Rechner" sind, so vermute ich, dass die unter Wikipedia unter "PACS" zu findenden Software Anwendungen gemeint sind (Picture Archiving and Communication System). Und genau hier sind eben die COM-Module mit AMDs APUs dabei. Das sind PACS-Rechner, die absolut keinen Bedarf an hoher CPU-Leistung haben, sehr wohl an hoher GPU-Leistung und vor allem Features. Ach und da kommt auch HSA zum Einsatz falls die vergesslichen User irgendwann wieder keinen Nutzen für HSA sehen. Ergänzend:

Siehe oben !! Alles schon erläutert. Und noch mal ein Befundungsrechner ist NICHT direkt an z.B. ein Röntgenpanel angebunden. ..ich habe auch nicht geschrieben, dass HSA da nicht interessant ist. Ich habe geschrieben wie der Status quo ist und wahrscheinlich leider (!!) auch bleiben wird. Lese meine Beiträge bitte etwas genauer und widerspreche nicht Dingen, die ich garnicht gesagt habe.

Daedal schrieb:
Kleiner Tipp: Google mal nach Videoprozessoren für die Endoskopie da sind plötzlich Kamerahersteller ganz weit vorne und nicht Nvidia. z.B. Pentax oder Olympus.
[/QUOTE]

Hä ? Die Panels werden auch nicht von nVidia hergestellt sondern von so Läden wie Thales. Geht es jetzt um Spezialhardware oder wat ?

Nicht komplett wirres Zeug komplett durcheinander quatschen und völlig unterschiedliche Applikationen in einen Topf werfen. ...und dabei bitte auch gucken worauf sich dieses Thema bezieht. Das ist nicht die Bildwiedergabe und auch nicht die Hersteller irgendwelcher Spezialhardware.
Wirr von meiner Seite war es allerdings, dass ich PACS und PAX durcheinander geworfen habe - hier wäre PACS in der Tat richtig gewesen.
Aber wenn Du schon Olympus nennst, dann ruf doch mal bei denen in Hamburg an und frag was für Geräte denn hinter dem Endoskop hängen. Wirst Dich wundern :-)

Ich lasse mich aber gerne eines besseren belehren. Bitte Link zu einem medizinisch zertifizierten (!!) Rechner (welcher Bauart auch immer) mit AMD CPU/APU oder GPU. Danke.
 
Zuletzt bearbeitet:
Was ja wohl eine IPC Verbesserung ist. Werden die Ausführungseinheiten breiter wie bei AVX, können auch mehr Befehle in selben Takt verarbeitet werden.
IPC = Instructions per Cycle. Nicht Arbeit pro Takt. Wenn man bei AVX-Code konsequent auf die Drei-Operanden-Befehle setzt, braucht man fast keine Moves mehr und erhält so möglicherweise niedrigere IPC-Werte als bei vergleichbarem SSE/x86-Code, trotz deutlich höherer Leistung.

Deswegen ist es auch genau so Blödsinn, im Zusammenhang mit HSA von irgendwelchen IPC-Werten zu reden - ebenso bei Intels QuickSync o.ä.
 
Als gibt es denn an "Instruction" großartig zu definieren? Das ist einfach ein Befehl, der irgendwo im Programm steht. Sowas hier.
Code:
vaddps ymm0, ymm1, ymm2

Aus dem Grunde existiert das ganze SIMD-Zeug (Single Instruction, Multiple Data) doch erst, weil sich IPC-Verbesserungen eben nicht unendlich weit treiben lassen.
 
guckmalrein schrieb:
Ich lasse mich aber gerne eines besseren belehren. Bitte Link zu einem medizinisch zertifizierten (!!) Rechner (welcher Bauart auch immer) mit AMD CPU/APU oder GPU. Danke.
pipip schrieb:

Krethi & Plethi schrieb:
komisch, gibt ja doch auch etwas anderes als intel in der medizin...
http://www.congatec.com/de/produkte/com-express/conga-baf.html

Daedal schrieb:
Wie viele willst du denn noch? Du musst das dort nur lesen. Zitate daraus:
So können viele hochkomplexe Berechnungen mit parallelen Rechenwerken in nur wenigen Rechenschritten (Takten) ausgeführt werden, für die eine klassische, serielle CPU bis zu mehrere tausend Schritte benötigen würde. Dadurch lässt sich die Rechenzeit und damit der Energieverbrauch für komplexe Rechenaufgaben drastisch senken. Gerade die bildgebende Medizintechnik mit ihrer ausgeprägten, vielfach gut parallelisierbaren Analytik kann von dieser Effizienzsteigerung enorm profitieren.

Wie hoch der Effektivitätsgewinn beim Einsatz von OpenCL auf heterogenen Systemarchitekturen ist, verdeutlicht eine Beispielapplikation: Für die Bildregistrierung, bei der es um die Stabilisierung eines Videobildes geht, arbeitet ein OpenCL basierter Algorithmus auf der GPU 120 bis 130 mal schneller als eine klassische Berechnung auf der x86-CPU.

COM-Express-Modul mit AMD R-Serie APU

Das COM Express Modul conga-TFS unterstützt derzeit drei Varianten der AMD Embedded R-Serie APUs, angefangen vom Dual-Core AMD R-272F APU bis zum Quad Core AMD R-464L APU. Das conga-TFS verwendet den AMD A70M Controller Hub und bietet eine leistungsfähige kompakte Zwei-Chip-Lösung mit Unterstützung für bis zu 16 GB Dual-Channel 1600MHz DDR3-Speicher.
 
Deswegen ist es auch genau so Blödsinn, im Zusammenhang mit HSA von irgendwelchen IPC-Werten zu reden - ebenso bei Intels QuickSync o.ä.

Wer hat das gemacht und hat HSA mit IPC Werten oder ähnliches verglichen ?

HSA bedeutet einfach, dass man ein Programm schreibt dass sowohl auf eine CPU only als auch auf eine HSA APU läuft. Der Unterschied ist, dass der Compiler der APU das dann effizient auf die jeweiligen Recheneinheiten (IGP, CPU, Instruction Set, DSP, je nachdem was verbaut ist) ordentlich zuweist und um Schritte zu sparen (Beispiel das herumkopieren) einen gemeinsamen Speicherraum mit gemeinsamen Adressen hat.

Aber nur zu Info, wenn hier von IPC gesprochen wird, wird wie Daedal schon erwähnt wird, meist sowieso nur von Games geredet oder eben Cinebench.

Ich finde die Frage eigentlich nicht so einfach geklärt. SIMD sind ja dazu da, dass sie spezielle Anwendungen/Berechnungen beschleunigen sollen.
Ob man das jetzt zur IPC dazuzählen darf, ist wohl Ansichtssache. Will man nur den Core betrachten und ist der Meinung, fix function zählt nicht dazu, dann hast du denke ich Recht.
Aber im Endeffekt muss die CPU auch den SIMD Induktionen vorgeben damit sie ausgeführt werden oder ? ;)


Das IPC Thema wurde ja wieder von den selben Leuten wie üblich angesprochen und man merkt auch, dass das komplette Thema APU wieder nur auf die IPC reduziert wird und alles auf Intel Niveau angepasst wird. Dass das Design dafür einen höheren Takt erlaubt oder ein Prozessor eben nicht nur aus IPC besteht, dass wird dann wieder bewusst ignoriert.
Das ist auch der Grund wieso ich was IPC angeht auch nicht mehr viel zu sagen habe, weil es sowieso am Ende immer wieder auf das selbe rauskommt.

Kurzel wie TDP, IPC, sind die aktuellen Marketingworte und sind vergleichbar mit GHZ, und GB RAM vor paar Jahren.

Nicht dass Watt/Core und Performance/Watt unwichtig sind, aber der Vergleich sagt nun mal eines aus. AMD hat 28nm und dessen APUs haben eine CPU die stark genug ist um die IGP auszulasten. Ziel sind die Tablets und Notebooks und Desktop wird in erster Linie erst 2016 wieder ein Thema bei AMD spielen.
Ein 3 Moduler hätte AMD ohne weiteres produzieren können, aber man hat sich für die 2 Modul Variante entschieden, weil es wichtig ist, die APUs in einer Preis-Region aufstellen zu können, wo es genug Abnehmer zu einen lohnenden Preis gibt. Das wird auch der Grund für Richland gewesen sein, Masken weiter auszunützen.
Eigentlich sollte AMD so klug sein, und dann noch eine weiter Revision mit kleineren Optimierungen und DDR4 auf den Mark bringen um die Maske noch mehr auszureizen.

Ich bin nur gespannt, was dann 2016 die neuen Marketing-Worte sind. Bin gespannt, wie dann AMD SMT Technik genannt wird. Aktuell ist es ja bei vorhanden Integer Core ein "unechter Core" im Vergleich zu Intels verdoppelter Register "virtueller" Core :D (das interessante ist doch, dass der verdoppelte Register in CMT auch vorhanden ist)

Aber man darf die Kreativität des CB Forum einfach nicht unterschätzten ^^


Ich erwarte mir von Excavator nicht viel, eher wird der Prozess und die Architektur eher noch die Effizienz nach unten steigern. Für den Desktop erwarte ich mir hiermit nicht viel.
Eventuell könnte der IGP Teil interessanter werden. Wer etwas über AMD Tonga weiß, könnte vllt nachvollziehen was ich hier anspreche.
 
Zuletzt bearbeitet:
Wer hat das gemacht und hat HSA mit IPC Werten oder ähnliches verglichen ?
Das bezog sich auf diesen Kommentar hier:
Kaveri hat beispielsweise eine drei bis fünf mal so hohe IPC gegenüber einem i5 von Intel durch Nutzung von HSA in LibrOffice

Ich finde die Frage eigentlich nicht so einfach geklärt. SIMD sind ja dazu da, dass sie spezielle Anwendungen/Berechnungen beschleunigen sollen.
Ob man das jetzt zur IPC dazuzählen darf, ist wohl Ansichtssache.
Natürlich zählen SIMD-Befehle zur IPC dazu, aber es geht ja eher darum, die Anzahl der nötigen Befehle zu verringern, indem ein einzelner Befehl mehr Arbeit erledigt (im Falle von AVX-256 eben in der Regel doppelt so viel wie vergleichbarer SSE-Code), und nicht darum, mehr Befehle der gleichen Sorte gleichzeitig auszuführen. Insofern ist der Begriff IPC auch nicht äquivalent zu Pro-Takt-Leistung (und schon gar nicht zu Pro-Kern-Leistung).

Ich bin nur gespannt, was dann die neuen Marketing-Worte sind.
Immer die, wo Intel nen Tacken besser ist, natürlich :evillol:

Ich erwarte mir von Excavator nicht viel,
Excavator dürfte so ziemlich die uninteressanteste Bulldozer-Iteration werden, aber es war ja mal die Rede davon, die Kerngröße auf Kosten der Taktraten zu verringern und darüber die Effizienz zu steigern. Wäre dann eben für Notebooks ganz nett, bisschen mehr Leistung bei gleichem Energiebedarf schadet bekanntlich nie.
 
Zuletzt bearbeitet:
Natürlich ist das exakt so, wie VikingGe schreibt. Doch schauen wir uns mal die hier in den Tests oder im Forum verbreitete Definition von IPC an dann ist das diese Formel: Gleicher Takt der CPU+Spiel XY mit meistem Grafikcandy auf schnellster GPU die derzeit verfügbar ist+GPU-Settings auf 800x600 damit es keine GPU-Limit gibt= FPS
Und die meisten Frames ergeben die beste CPU IPC :freak:

Also da bin ich deutlich näher bei der korrekten IPC Definition inkl. HSA. Obwohl die meisten Vorteile gar nicht mit CPU oder GPU Berechnungen zu tun haben, sondern mit der Datenverteilung und dem Zugriff beider Rechenwerke. Nur warum stellt das keiner in Frage bei IPC-Werten basierend auf FPS? Ob da IO eine Rolle spielt wird von den meisten einfach ignoriert mit der Begründung man hebe das GPU-Limit auf durch niedrige Auflösung.
 
Daedal schrieb:
Wie viele willst du denn noch? Du musst das dort nur lesen. Zitate daraus:

Hätte hätte Fahrradkette. Ja, ja wird alles gefragt und es gibt auch tolle Module.. alles klar. Ich will aber sehen wo das dann auch in der Praxis zu finden ist. Noch mal und nur für Dich: ich streite nicht ab, dass das nicht interessant ist ich streite ab, dass es zum EINSATZ kommt. Ist es so schwer den Inhalt meiner Beiträge zu verstehen ?
Da hast noch kein einziges Beispiel genannt und wirst wahrscheinlich auch keines nennen können.
Fujitsu hat seit Jahren (!!) Mainboards mit AMD-Prozessoren im Einsatz, Fujitsu Mainboards bringen ALLE Anforderungen für diesen Bereich mit sich und trotzdem findest Du deren Mainboards mit AMD-CPUs meines Wissens nicht in Computern, die durch das Medizinproduktegesetz berührt werden. Das sieht mit den Fujitsu Mainboards mit Intel CPU aber anders aus. HSA hin oder her so ist das leider.
..und noch mal: Du brauchst mir die Vorteile von HSA & Co. nicht auflisten. Das ist alles bekannt und nichts neues - das ist sogar nen alter Hut. Bringt nur alles nichts wenn es nicht eingesetzt wird. Selbst im Consumer-Bereich gibt es bis heute kaum Anwendungen, die von den APUs profitieren. Nicht weil die Architektur schlecht ist sondern weil es sich offensichtlich nicht lohnt die Applikationen anzupassen. Wenn das schon im Consumer-Segment so ist gilt das potenziert für den Medizinbereich.
 
Zuletzt bearbeitet:
Da hast noch kein einziges Beispiel genannt und wirst wahrscheinlich auch keines nennen können.
Dazu muss man aber auch zur Verteidigung sagen, du hast nicht geantwortet ob deine Aussage jetzt spezifisch dein Umfeld, Deutschland oder global zutrifft. Denn es scheint at least so, dass AMD APUs im Vergleich zu anderen Lösungen teils auch günstiger sein könnte. Kannst du uns sagen, dass AMD APUs in Asien, so wie Indien oder in Amerika nicht in Geräte wieder zu finden sind ?

Wenn das schon im Consumer-Segment so ist gilt das potenziert für den Medizinbereich.
Wie kann man den Consumer Segment bitte mit dem embedded Markt vergleichen ?
Wie ich schon schrieb, besonders AMD ist mit deren APU sehr attraktiv, weil eine Firma jetzt sogar gezielt einen angepassten SoC bestellen kann und je nach Wunsch bei diversen Auftragsgeber herstellern kann (GF, Samsung, TSMC, ect), der alles integriert hat, auch diverse DSP falls gefragt sind (AMD ARM Opteron hat sogar einen DSP integriert).
Software wird in Server-Umfeld und auch für spezielle Geräte doch angepasst ? Oder spricht du von den Office Geräten die man so für Befunde stehen hat und eigentlich nur herkömmliche Office-Rechner sind ?

Aber was genau die Anpassung angeht, wäre ja dann HSA eventuell sogar ein richtiger Vorteil (wenn das stimmt womit die HSA Foundation wirbt), oder denkst du nicht ?
 
Zuletzt bearbeitet:
In den aktuell wichtigen Märkten (USA, Europa, Japan) kann ich das sagen - da gibt es nicht so viele Spieler in dem Bereich. Indien, China usw. ist was ganz anderes - da sind die Normen und Kontrollen viel viel lascher als in den oben genannten Märkten.
Allerdings spielt da auch noch die Software eine Rolle - und die dürfte (das weiss ich aber nicht mit Gewissheit) auch in diesen Märkten AMD nen Strich durch die Rechnung machen.
Und wenn man z.B. von PACS Großrechnern ausgeht gilt das sogar global. Denn da gibt es noch weniger Spieler und was Firmen wie GE, Toshiba, Siemens, Philips etc. weiss ich.
Das selbe gilt in sehr ähnlicher Form für den Bereich embedded - wenn die indirekte Wertschöpfung durch die Rechner geringer ist, sind Plattformwechsel natürlich einfacher zu vollziehen. Aber Themen wie "Factory 2.0 3.0" oder wo wir da gerade sind, sind in China und Indien mal vollkommen egal. ..und es wird auch noch nen Weile dauern bis die sich ernsthaft mit Effizienz auseinandersetzen müssen.
 
Zuletzt bearbeitet:
guckmalrein
Aber der Vorteil der HSA APU soll es ja sein, dass man quasi nur Bioblotheken erweitern braucht und die APU selbst über einen eigenen Compiler je nach Anwendung die Aufgaben verteilt. Es wird also nicht so wie bei OpenCL oder Cuda spezielle starke Anpassungen gefordert, wenn man eben glauben darf, was die HSA Foundation sagt.
Aktuell kann Kaveri soviel ich weiß noch kein Context-Switching, somit eventuell hört man dann zu Release zu Carrizo mehr Details.

http://www.tomshardware.de/fusion-hsa-opencl-Geschichte-APU,testberichte-241088-8.html
Falls du den Artikel nicht kennst.
 
Zu Deiner Frage was der Consumer-Bereich mit dem embedded Bereich zu tun hat. Es zeigt wie lange es dauert bis sich neue Architekturen auch auf Software-Basis etablieren. Das gilt aber noch viel extremer für den embedded Bereich. ..und noch krasser für den Medizinbereich, da dort auch Software Bestandteil einer Zertifizierung sein kann.
Um es noch mal zu sagen: ich habe nicht gesagt, dass HSA Unsinn oder Schwachsinn ist (wenn es denn irgendwann mal wie gewünscht funktioniert), ich sagte wie es aktuell ist und habe geschildert warum es AMD in diesem Bereich verdammt schwer haben wird - selbst wenn die Architektur dann irgendwann mal final steht.
Momentan wird der Embedded-Bereich von Intel und ARM dominiert. ...und da es ja so schön heißt "never touch a running system", wird AMD schon richtig schwere Kaliber auffahren müssen, damit sich Entwickler daran trauen das System dann doch mal anzufassen.
Im Falle von CUDA z.B. sind die Anpassungen ja schon gemacht - ganz einfach weil es "damals" keine Alternative gab bzw. die Vorteile so enorm waren. Ich glaube nicht, dass AMD es in absehbarer Zeit schafft die Entwickler noch ein mal so zu motivieren.
Ich wollte mit meinem ursprünglichen Post auf den Umstand hinweisen, dass AMD es sehr schwer haben wird in diesen Markt zu kommen und warum. Das war keine Bewertung der Architektur.
Letztendlich hat AMD doch auch vor Erscheinen der Intel Core Architektur keinen riesigen Vorteil aus seiner überlegenen Architektur ziehen können - und das galt "nur" für den Bereich Server und Consumer, wo Hardware einfach austauschbar ist. Auch das gilt wieder potenziert für den embedded und Medizin-Bereich. Traurig aber wahr - ich würde AMD mehr Erfolge wünschen, denn von diesen Quasimonopolen haben wir Kunden nichts. Letztendlich verdienen die Hersteller ihr Geld ja im profesionellen Bereich - und da sieht es für AMD auf allen Fronten ziemlich böse aus.

Es geht niemanden etwas an was ich genau mache. Aber es ist schon verdammt schwer AMD an den Mann zu bringen. Im Medizinbereich höre ich nur "AMD ? Ich mag die. Kauft aber keiner - besteht kein Interesse." und weiter braucht man garnicht diskutieren. Solche Sätze darf ich mir regelmäßig anhören. Es ist nicht so, dass AMD unbeliebt ist - es wird nur einfach nicht nachgefragt. Bekomm das mal wieder aus den Köpfen - hat wie gesagt früher schon bei deutlich "einfacheren" Kunden nicht richtig funktioniert obwohl Intel da nun wirklich eine im Vergleich extrem schlechte Architektur hatte.
 
Zuletzt bearbeitet:
guckmalrein schrieb:
Hätte hätte Fahrradkette. Ja, ja wird alles gefragt und es gibt auch tolle Module.. alles klar. Ich will aber sehen wo das dann auch in der Praxis zu finden ist. Noch mal und nur für Dich: ich streite nicht ab, dass das nicht interessant ist ich streite ab, dass es zum EINSATZ kommt. Ist es so schwer den Inhalt meiner Beiträge zu verstehen ?
Nein ist es nicht. Nur anscheinend ist es schwer für dich zu verstehen, dass die Links zu einem fertigen Produkt, das ausschließlich für die Medizin produziert wird führen. Das sind keine Komponenten, sondern fertige Produkte inkl. Software die Congatec anbietet. Muss ich dir auch detailliert zeigen wo ein iMac im Büro steht damit du akzeptierst, dass dieses Produkt existiert? Ich habe auch noch nie eine derartige Forderung bei Intel Produkten gehört.
 
Wo ist das ein komplett fertiges Produkt inkl. Software ? Ich sehe da weder ein Netzteil noch ein Gehäuse (das beides relevant für eine EMV ist, was Du natürlich weißt). Das ist ein Bausatz mehr nicht.
Edit: das ist nicht mal ein Bausatz sondern ein Bestandteil eines Bausatzes.
..ach so und bei Intel Systemen kann ich Dir sofort Links zu fertigen Produkten schicken.
 
Zuletzt bearbeitet:
Daedal schrieb:
Explore real applications that are leveraging AMD heterogeneous technologies.
Diese Liste habe ich schon mehrfach gepostet und Kaveri HSA Benchmarks kannst du googeln ich schlage vor "Kaveri Test HSA" als Suchbegriff. Ich bin sicher die Hälfte der Treffer verweist auf Beiträge von mir bei denen ich dir geantwortet habe und die Benchmarks verlinkt habe.

Kaveri Test HSA gegoogelt, leider kaum eine App von der Liste gefunden die mal gegen andere CPU ohne HSA antritt. Die Liste ist eh toll. Spiele kannste schon mal rausnehmen, der Rest bezieht sich quasi ausschließlich auf OpenCl Support was die Konkurrenz auch kann. Hier wäre es interessant wie zb, um beim realistischsten zu bleiben, Winzip 18 von HSA profitiert.
Man könnt meinen HSA = OpenCL wenn man die Liste anschaut...

Mit das Einzige was man noch findet is LibreOffice mit HSA Test.

Was hab ich nun in GIMP davon? Ich hätte gern Zahlen Werte, müsste halt mal jemand testen. Wenn ich natürlich den Überfilter auf 100MP anwenden muss um nen Vorteil zu sehen ist das relativ, wichtiger wäre da schon sowas wie der reine Export nach JPEG.

Die Frage ist auch... wer nutzt Apps wie GIMP zur professionellen Bildbearbeitung zb auf einem Tablet? Wieso auf Tablet... nun ja, weil ich mir mit ner 100€ Grafikkarte im PC 3x mehr OpenCL Leistung erkaufen kann und das logischerweise auch machen würde sofern es mir Vorteile bringt.

Bei den Video Tools ist meist der Export, das Wandeln das zeitkritische - und da hängt Quicksync OpenCL weit ab... letzteres bringt magere % Werte bei zb Handbrake.

P.S: Ich suche keine Benchmarks in Form von einen Computing Tests wie Luxmark.

Edit: Am ehesten noch hier:

http://www.tomshardware.com/reviews/a10-7850k-a8-7600-kaveri,3725-13.html

winzip.png


vegas.png


handbrake.png


schon recht mau was man bei diesen halbwegs realistischen Apps über OpenCL aka HSA rausholt. Find ich.

Wohlgemerkt wirbt AMD in deiner Liste mit WinZip 18 und Sony Vegas Pro 12...

Edit:
Ich bleib dabei. Für heutige Software, selbst in AMDs HSA SW List... is man zumeist CPU limitiert. Scheinheilige Benchmarks wie

09-LibreOffice-OpenCL.png


ist eher Märchenwelt. Vielleicht geht es bei einzelnen Anwendungen, zb beim Decrypten von Passwörten in diese Richtung - aber ich erwarte keinen auch nur 20% schneller bootenden PC durch HSA. Und bauch ich OpenCL, weil ich zb ein Hobbyhacker oder Cruncher bin, dann kauf ich mir ne 290X.


Edit:

Noch was zu HSA

http://www.extremetech.com/computin...-wait-for-the-first-true-heterogeneous-chip/5

HSA-Corel.png



-> wenn HSA mal wirklich Vorteile ausspielt, muss es sich zudem noch bei der Effizienz beweisen.
 
Zuletzt bearbeitet:
Krautmaster schrieb:
Man könnt meinen HSA = OpenCL wenn man die Liste anschaut...
Mir scheint du wirst es nie verstehen was HSA ist. HSA ist nichts AMD exklusives. OpenCL kann weder die VCE Unit noch die UVD Unit ansprechen, während einige der dort gelisteten Programm heterogen auf CPU+VCE oder CPU+UVD zugreifen. Das nennt sich dann Heterogenes Computing. Ausser OpenCL kann das auch C++ oder C++ AMP.

Dein Vergleich zwischen Quicksync und OpenCL ist so albern, dass ich gar nicht weiss was ich dazu sagen soll. Quicksync kannst du mit der UVD und VCE Einheit vergleichen, aber kaum mit einer Progrmmiersprache.

Bei dir ist HSA=CPU+GPU
Und das ist der immer wieder kehrende Fehler bei dieser Betrachtung. Dir fällt noch nicht mal auf, dass sämtliche Mantle Spiele dort unter heterogenem Computing gelistet sind. Na denk mal darüber nach was dort wohl heterogenes Computing sein könnte?

Ein Beispiel Corel Aftershot Pro 2.0 enthält OpenCL Filter die ca. 1,6 mal so schnell sind als CPU Optimierte Fiter. Also ein Plus von 60% ganz ohne HSA. Nun gibt man dazu HSA und die Beschleunigung von OpenCL steigt nochmals. HSA hat in dieser Software manche Filter überhaupt erst möglich gemacht mit OpenCL, die ohne HSA auch mit OpenCL keinen Geschwindigkeitsvorteil bringen. Aufgrund der Verluste beim verschieben der Daten in üblichen OpenCL Programmen. Detailliert mit Code kann man das hier nachlesen:
Pressemeldung: http://web.amd.com/assets/CustomerReferenceProgramPackage2012/CRP AfterShot Pro Jan 2014.pdf
Präsentation auf Developer Sumit: http://de.slideshare.net/DevCentralAMD/hc-4020-michaelwootton
Bevor es wieder nicht gelesen wird:
SOLUTION:
Verschlüsselung ohne Performance Aufschlag ist das HSA Feature in Winzip. Kann man gespannt sein wer das testet.
 
Zuletzt bearbeitet:
mir is durchaus klar, dass HSA != OpenCL ist. (nur schient OpenCL MAD mittel der Wahl zur Präsentation ihrer APUs zu sein - und dabei scheut man nicht mit "HSA" um sich zu werfen)

Der Vergleich OpenCL und Quicksync ist nicht technischer Natur gewesen, das war doch klar. Es geht beim Vergleich darum was dem Endanwender heut mehr bringt. 5% Gewinn durch Hinzuschalten von OpenCL(mit oder ohne HSA)oder ne Reduktion der Encoding Zeit von XX min auf wenige Minuten (bei CPU vs Quicksync).

Es ging um den Nutzen für den Endanwender da HSA hier Teils so aufgeblasen wird, als wäre es der heilige Gral der Chipentwicklung/Programmierung.

Auch ist mir das mit den Spielen durchaus klar oder meinst ich denk AMD hat da willkürlich 20 DX Titel reingedampft :P

An die Aussage HSA != CPU+GPU... nun ja, stand heute gibt es wenig Fälle bei denen HSA als Heterogenes Computing Vorteile zieht, auf Architektur Ebene oder bei der Programmierung. Das zeigt sich daran, dass die meisten "HSA Benches" genauso gut bei CPU + ext. GPU skalieren.

Was die AES Sache angeht... HSA or not? AES is doch eh in Hardware bei allen SOC von AMD, dessen Bandbreite locker für Echtzeit Verschlüsselung reicht. Das AES hier mit HSA unter einen Deckel zu werfen ist so falsch wie der Vergleich mit Quicksync. (dazu müsste man wohl ne CPU ohne AES Befehlsatz wie nen i3 mit ner HD290X be Winzip 18 und AES testen... um zu sehen ob nicht einfach AES in CPU genutzt wird und hier gemeint ist oder wirklich ein AES Algo auf GPU berechnet wird)

@Corel Aftershot Pro 2.0

60%... sind wenig wenn man bedenkt dass es sich um eine grafische Anwendung handelt. HSA / Auslagerungen / Optimierungen auf GPU greifen natürlich dort am besten, wo man extrem parallelisiert rechnen kann. Pixel bzw Bilder sind hierfür wie gemacht- vor allem wenn diese weitestgehend unabh. voneinander berechnet werden können. Sicher, 60% sind top. Davon profitiert sicher 1-2% der PC Nutzer. Auch da wäre wieder interessant wie gut eine R9 290X im Vergleich abschneidet, ergo ob hauptsächlich die blanke GPU Power ne Rolle spielt oder wirklich das ineinander Greifen der HSA Methodiken.

Ich hab nichts gegen HSA oder OpenCL usw... jede Beschleunigung ist gut aber man sollte doch mit eigenen Erwartungen nicht vollkommen überzogen dastehen. Je nach Anwendung bringt HSA in Zukunft vielleicht den Unterschied wenn es darum geht wie gut meine 40 MP Fotos auf einem Tablet anschauen kann, ob es ruckelt oder nicht und genau da bringt diese Optimierung auch massiv was. Beim heutigen Desktoprechner Kauf wäre aber HSA mit das Letzte auf das ich achten würde.
 
Zuletzt bearbeitet:
Das HSA derzeit vergleichsweise wenig bringt wenn es um CPU+GPU geht wird wohl auch daran liegen, dass Software derzeit kaum darauf angepasst ist. Schon solche Sachen wie ZeroCopy, derzeit ist das Umherschieben von Daten so Laufzeitintensiv, dass es oft nicht lohnt die Daten zu verschieben um sie auf spezialisierter Hardware laufen zu lassen. Wenn das Umherschieben von Daten nun aber quasi Laufzeitneutral stattfinden kann man Software schreiben die fleißig Daten schiebt was man derzeit recht oft vermeidet.

Kurzum, Software und Algorithmen die mit HSA wirklich gut klar kommen werden sich noch entwickeln müssen. Ebenso wie ja multithreaded Software sich entwickeln musste (und bei einigen Programmen noch immer in den Kinderschuhen steckt).



Was auch gerade Sachen wie H264 angeht, H264 ist recht integerlastig. Da bringt eine GPU zwar auch etwas, aber im Vergleich zu dem was da an zusätzlicher Floatingpointleistung verfügbar wäre ist das eher lächerlich. Hinzu kommt, dass H264 nicht all zu gut auf massive Parallelisierung ausgelegt ist. Handbrake zum Beispiel skaliert mit vielen CPU Kernen auch erst bei hoher Qualität und hoher Auflösung, massiv paralleles Encoding braucht da dann wohl recht unübliche Videos ;)
Genauso sind viele Kompressionsalgorithmen auf GPUs kaum zu beschleunigen. Der Entwickler von 7zip und damti dem LZMA(2) Algorithmus lehnt die Portierung auf OpenCL schlicht ab, weil sein Algorithmus auf GPUs überhaupt nichts bringt (und der versteht sein Handwerk :) )
 
Zuletzt bearbeitet:
Zurück
Oben