AMD Kaveri: Erstes Engineering-Sample aufgetaucht

Stegan

Redakteur
Hardwareluxx Team
Thread Starter
Mitglied seit
16.12.2005
Beiträge
16.199
Ort
Augsburg
<p><img style="margin: 10px; float: left;" alt="AMD Logo 2013" src="/images/stories/logos-2013/AMD_Logo_2013.jpg" height="100" width="100" />AMDs „<a href="index.php/news/hardware/prozessoren/28419-amd-kaveri-paperlaunch-im-dezember-verfuegbarkeit-ab-februar-2014.html">Kaveri“-APUs sollen Anfang Dezember vorgestellt werden, aber erst im Februar des nächsten Jahres in den Handel kommen</a>. Vermutlich wird <a href="http://www.amd.com/de/pages/amdhomepage.aspx" target="_blank">AMD</a> die CES 2014 Anfang Januar nutzen, um die Aufmerksamkeit auf seine neuen APUs zu ziehen und vermutlich auch im Zuge des Developer Summits, der am 11. November in San Jose starten wird, weitere Informationen preisgeben. Nun tauchte auf der chinesischen Webseite vr-zone.com ein erstes Foto eines Prototypen...<br /><br /><a href="/index.php/news/hardware/prozessoren/28503-amd-kaveri-erstes-engineering-sample-aufgetaucht.html" style="font-weight:bold;">... weiterlesen</a></p>
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"Zwei A10-APUs der High-End-Klasse und ein Modell der A8-Reihe des leistungsschwächeren Performance-Segments."

also wohl doch 2 moduler als high end. die A8 gabs bei richland nur als 1 moduler oder ?
 
Wobei der Zusammenhang zwischen HighEnd und zwei Moduler nicht ganz klar ist :fresse:
HighEnd ist für mich was anderes... Da kommt aktuell keine APU überhaupt nur ansatzweise hin.
 
Naja, mit 20% Merhleistung kommt man immerhin schon an Intels Sandy/Ivy i5 ran, ist aber immernoch eher Mittelklasse.
 
das ist logisch du nasenbär ;) wenn das high end Modell A10 2 module hat, sind die 60% günstigeren A6 bei gleicher takt rate sicher keine 2 moduler.

Das war eine Antwort darauf:

die A8 gabs bei richland nur als 1 moduler oder ?

;)

Wobei der Zusammenhang zwischen HighEnd und zwei Moduler nicht ganz klar ist :fresse:
HighEnd ist für mich was anderes... Da kommt aktuell keine APU überhaupt nur ansatzweise hin.

Ich glaube für die meisten Hersteller ist High End, das obrige Ende des Portfolios... :d
 
hab grad auf alternate gecheckt das A8 auch 2 moduler sind, und A6 und A4 1 Moduler sind. mal gespannt was da kommt.
 
Das ein A10-6800k nur 20% Rückstand auf nen i5-3570k hat ist wohl eher Wunschdenken seitens AMD und deren Anhänger. Eher 40%, wenn sich Produktivity- und Render-Benchmarks anschaut.

Wenn es um Multithreading geht, dürfte da sogar noch mehr auf der Uhr stehen...
Man bedenke, der i5 ist nur unwesentlich (15-25%) hinter dem schnelleren i7 mit SMT zurück -> eben weil kein SMT.
Die APUs um die es hier geht, sind aber nur zwei Moduler. Sprich halbe FX8xxx CPUs. Da letztere im MT im Schnitt auch nur i7 Sandy/Ivy Leistung erreichen, wären 50% weniger Module eben ne ganze Ecke weniger...

Die Frage ist und bleibt, was wird die geänderte CPU Technik da hintenraus noch reißen können... Echte Wunder würde ich aber irgendwie da nicht unbedingt erwarten :(
Wenn man sich die IPC Steigerung der Intels seit Sandy ansieht, stehen da heute zu Haswell schonmal locker 50% auf der Uhr, die AMD aktuell zu fehlen scheinen. Und das trotz höherer Taktraten der aktuellen APUs.
Steamroller wird das aus meiner Sicht nicht rausholen können. Wäre dies der Fall, würde AMD wohl die große Werbetrommel läuten. :wink:
Auch die GPU wird da nichts dran ändern. Bis diese irgendwann in Jahren oder Jahrzenten mal so flächendeckend in Software angesprochen wird, wird auch ein Kaveri AMD APU Modell mehr als Alteisen sein. :(
Sieht man doch auch an Llano heute... Das Ding ist noch viel mehr lahmer als ne 6800K APU. Und kann trotz ansprechender GPU Power neben einer Hand voll Anwendungen sogar keinen Nutzen aus dieser ziehen... Und die Teile gibts immerhin seit fast 2,5 Jahren schon.
 
Sieht man doch auch an Llano heute... Das Ding ist noch viel mehr lahmer als ne 6800K APU. Und kann trotz ansprechender GPU Power neben einer Hand voll Anwendungen sogar keinen Nutzen aus dieser ziehen... Und die Teile gibts immerhin seit fast 2,5 Jahren schon.

Kaveri stellt die erste richtige APU dar (Fusion beendet) jetzt können der CPU Gleitkommaoperationen abgenommen werden.

Offizielle Bulldozer-Folien - Hardware-Infos

"Werden alle Module mit Integer-Berechnungen belastet, sind nur noch maximal 3,9 GHz möglich, bei Gleitkommaberechnungen setzt der Turbo unter Umständen gar nicht ein. Der Verdacht liegt nahe, dass Bulldozer bereits als Bestandteil einer APU konzipiert wurde wie sie in Form von Trinity bereits im Frühjahr 2012 erscheinen soll. Hier würden, die entsprechende Software vorausgesetzt, die GPU-Teile der APU die Gleitkommaberechnungen übernehmen und diese wahrscheinlich deutlich effizienter verarbeiten. "
 
Zuletzt bearbeitet von einem Moderator:
Die Quelle ist von 2011 und "Fusion beendet" ist da auch nicht, auch mit Kaveri hat man einen CPU- und einen GPU-Part. Eine Rechnereinheit für beides, also eine Fusion aus CPU und GPU, hat man damit immer noch nicht.
 
So schaut es aus... Auch Kaverie ist CPU nebst GPU.
Es gibt Überschneidungen bzw. nennen wir es Verbindungen zwischen beiden, die die gemeinsame Arbeit effizienter gestalten. Eben HSA bzw. hUMA beispielsweise...
Das ändert aber nix daran, das die Software, die eine Int. oder Gleitkommazahlenberechnung lostritt nur in den CPU Modulen berechnet wird. Das ist und bleibt Fakt. (Stand heute)
Um diesen Umstand zu ändern, benötigt man eine angepasste Software, die eben die ALUs der GPU ansprechen kann... Und vor allem auch noch einer Logik, die erstmal prüft, macht es denn überhaupt Sinn die Berechnung auf die GPU zu schieben, oder bin ich womöglich mit der CPU gar schneller?

Das ist exakt die gleiche Bedingung, wie sie seinerzeit Llano auftat -> und wie sie jede andere CPU + GPGPU fähige GPU stand heute ebenso auftut.
Ist diese nicht erfüllt, ist essig mit GPU Beschleunigung und man kann den GPU Part in der APU ebenso gut vollständig deaktivieren und sich ne 20 Jahre alte PCI Grafikkarte für die Bilddarstellung in die Hütte stecken und hätte exakt die selbe Rechengeschwindigkeit seiner Software wie bei aktiver GPU der APU.


Wann bzw. ob irgendwann mal überhaupt der "CPU" direkt Einheiten heutiger GPUs beiseite gestellt werden um eben den Spaß in Hardware und somit vollständig ohne Softwareanpassungen umzusetzen, bleibt abzuwarten und steht noch in den Sternen. :wink:
Ich würde aber sagen, das kommt früher oder später ;)
Seinerzeit wurde der CPU auch ein externer CoProzessor nebengestellt. Oder es wurden Cache Module aufs Board gesteckt usw. usf.
Über die Jahre ist das alles in die CPU gewandert. Auch macht die CPU heute einen Großteil der Kommunikation in sich selbst wo damals zu FSB Zeiten noch der Chipsatz quasi das zentrale Glied war und die CPU nur am FSB hing...
Kommen wird das also wohl definitiv früher oder später... Die Frage ist, wann!? ;)
 
Nicht schon wieder, ...

So schaut es aus... Auch Kaverie ist CPU nebst GPU.
Es gibt Überschneidungen bzw. nennen wir es Verbindungen zwischen beiden, die die gemeinsame Arbeit effizienter gestalten. Eben HSA bzw. hUMA beispielsweise...
Das ändert aber nix daran, das die Software, die eine Int. oder Gleitkommazahlenberechnung lostritt nur in den CPU Modulen berechnet wird. Das ist und bleibt Fakt. (Stand heute)
Um diesen Umstand zu ändern, benötigt man eine angepasste Software, die eben die ALUs der GPU ansprechen kann... Und vor allem auch noch einer Logik, die erstmal prüft, macht es denn überhaupt Sinn die Berechnung auf die GPU zu schieben, oder bin ich womöglich mit der CPU gar schneller?

Wo ist daran bitte das Problem? Lass den Compiler doch seinen Job erledigen, ... Das ist nichts anderes als mit den ganzen Befehlssätzen, die wir eh schon haben, AVX beschleunigt auch keine alten Programme.
Hast du überhaupt eine Ahnung von Softwareentwicklung?

Das ist exakt die gleiche Bedingung, wie sie seinerzeit Llano auftat -> und wie sie jede andere CPU + GPGPU fähige GPU stand heute ebenso auftut.
Ist diese nicht erfüllt, ist essig mit GPU Beschleunigung und man kann den GPU Part in der APU ebenso gut vollständig deaktivieren und sich ne 20 Jahre alte PCI Grafikkarte für die Bilddarstellung in die Hütte stecken und hätte exakt die selbe Rechengeschwindigkeit seiner Software wie bei aktiver GPU der APU.

Der Unterschied zwischen Kaveri, Llano und CPU-GPU-Gespannen ist wie du oben schon gesagt hast HSA (hUMA, hQ, ...). Der Code muss sich nicht erst durch zig Ebenen (Treiber, verschiedene Speicher, ...) kämpfen um die GPU anzusprechen, der Thread kann direkt an die GPU weiter gereicht werden.

Was erwartest du denn von dem HSA-Konzept? Das es MS-DOS beschleunigt?

Wann bzw. ob irgendwann mal überhaupt der "CPU" direkt Einheiten heutiger GPUs beiseite gestellt werden um eben den Spaß in Hardware und somit vollständig ohne Softwareanpassungen umzusetzen, bleibt abzuwarten und steht noch in den Sternen.

Um zu erkennen, ob sich nachfolgende Code besser auf der CPU oder GPU berechnen lässt, müsste man ihn in realtime analysieren. Also erst mal die nächsten sagen wir 100 Befehle vor laden, nach Schleifen oder anderen parallelisierbarem Dingen prüfen, der CPU bzw. GPU dann mit teilen, was wo ausgeführt werden soll. Und das müsste dann mit einem Vielfachen des Prozessortaktes ablaufen damit die APU nicht gebremst wird. Glaubst du wirklich das wird jemals in eine APU kommen?

Das ist Wunschdenken aber sicher nicht technisch machbar.
 
Wo ist daran bitte das Problem? Lass den Compiler doch seinen Job erledigen, ... Das ist nichts anderes als mit den ganzen Befehlssätzen, die wir eh schon haben, AVX beschleunigt auch keine alten Programme.
Hast du überhaupt eine Ahnung von Softwareentwicklung?

Ja leider habe ich diese "Ahnung"... Deswegen scheint auch meine Sicht anders auf die Dinge zu sein, als bei so manchem Euphoriker :wink:
Und klar kanns der Compiler zum Teil richten... Ja und? Sag das nicht mir, sag das den Leuten, die die ganze Software auf den Markt gebracht haben...
Ich kann nix für, das die neuen CPUs von AMD ihre Leistung erst entfalten, wenn da FMA und Co. in use sind... Und ich kann ebenso wenig für, das diese eben scheinbar in der Leistung zurück liegen, wenn man es nicht macht genau so wenig wie ich dafür kann, das die APU stand heute nur dann die GPU mitrechnen lässt, wenn die Software dediziert diese anspricht.

Erklär mir dochmal, warum ich mir dafür den Deckel aufsetzen lassen soll? Nur weil ich den Umstand anspreche? Und so nicht gut heißen kann? Sorry, aber was soll das?

Der Unterschied zwischen Kaveri, Llano und CPU-GPU-Gespannen ist wie du oben schon gesagt hast HSA (hUMA, hQ, ...). Der Code muss sich nicht erst durch zig Ebenen (Treiber, verschiedene Speicher, ...) kämpfen um die GPU anzusprechen, der Thread kann direkt an die GPU weiter gereicht werden.

Was erwartest du denn von dem HSA-Konzept? Das es MS-DOS beschleunigt?

Was ich erwarte, ist doch völlig nebensächlich...
Mir ist das doch vollkommen egal, wer da auf dem CPU Deckel steht. Ich kaufe nach P/L. Und "L" definiert die Software die ich habe bzw. zu Benutzen gedenke. Also richtet sich die Kaufentscheidung einzig daran...

Und zum anderen, das ist auch schön so... Nur was macht dieses Wissen für einen Unterschied? Ohne Software, nix mehr Performance... Das Endresultat stand heute hat sich dahingehend nicht geändert. Oder steh ich auf dem Schlauch!?

Um zu erkennen, ob sich nachfolgende Code besser auf der CPU oder GPU berechnen lässt, müsste man ihn in realtime analysieren. Also erst mal die nächsten sagen wir 100 Befehle vor laden, nach Schleifen oder anderen parallelisierbarem Dingen prüfen, der CPU bzw. GPU dann mit teilen, was wo ausgeführt werden soll. Und das müsste dann mit einem Vielfachen des Prozessortaktes ablaufen damit die APU nicht gebremst wird. Glaubst du wirklich das wird jemals in eine APU kommen?

Das ist Wunschdenken aber sicher nicht technisch machbar.

Es muss ja keine Perfekte Lösung sein ;)
Sprungvorhersagen beispielsweise gibts nicht erst seit heute... Und die laufen eben auchmal ins leere. Aber es gibt sie und ohne sie wäre der Speed wohl auch deutlich? schlechter als mit.

Im Endstadium von Fusion sollte das aber auch weniger eine Rolle spielen. Nämlich wenn ALUs beispielsweise der CPU so beiseite gestellt werden, das beispielsweise jegliche Gleitkommaoperationen auf diesen ablaufen.
Eventuell löst man sich so auch irgendwann vom klassischen "Core" CPU Konzept. So gibt es dann eben nicht mehr die klassichen CPU Cores oder auch CPU Module in CMT Bauweise, sondern es gibt nur noch Int Cores mit ner ganzen Latte von Gleitkommaprozessoren beispielsweise. Gepaart mit ner Einheit, die eben die Berechnungen in Hardware auf die ALUs verteilt...
Nur ist das alles Zukunftsmusik...

Heute bzw. Morgen sehen wir eine CPU mit zwei Modulen in Form von Steamroller Cores, der eine GPU auf GCN Basis beseite gestellt wird und zwischen welchen die Möglichkeit besteht auf einen gemeinsamen Speicherbereich zugreifen zu können. Mit Ausnahme der shared Memory Funktion bleibt die GPU aber GPU und der CPU Part eben CPU.
Und wie gesagt, mach mich bitte nicht dafür verantwortlich, ich kann da nix für :wink:
 
Das ist mir zu pauschal. Andernfalls dürfte der Bulldozer niemals den i7 4960x abhängen. Dies schafft er aber. Und dort kommt nur SSE2 zum Einsatz. Ist zwar nur ein Test widerlegt aber wunderbar deine getätigte Aussage: [Phoronix] Intel Core i7 4960X Linux Performance (Ivy Bridge E) Review Man beachte, dass der intel Prozessor sogar höher taktet.

auffallend sollte doch sein, das die Aussagen auf die Durchschnittsperformance zielen!?
Was interessiert cherry picking?
Das geht andersrum genau so gut... :rolleyes:
 
Ja leider habe ich diese "Ahnung"... Deswegen scheint auch meine Sicht anders auf die Dinge zu sein, als bei so manchem Euphoriker :wink:
Und klar kanns der Compiler zum Teil richten... Ja und? Sag das nicht mir, sag das den Leuten, die die ganze Software auf den Markt gebracht haben...
Ich kann nix für, das die neuen CPUs von AMD ihre Leistung erst entfalten, wenn da FMA und Co. in use sind... Und ich kann ebenso wenig für, das diese eben scheinbar in der Leistung zurück liegen, wenn man es nicht macht genau so wenig wie ich dafür kann, das die APU stand heute nur dann die GPU mitrechnen lässt, wenn die Software dediziert diese anspricht.

Schau dir doch mal die Geschichte der Hard/-Softwareentwicklung an. Es kam noch nie vor, dass ein Feature von der Software genutzt wurde, bevor es spezifiziert oder die Hardware da war. Ein sehr gutes Beispiel ist wohl die FPU bzw. damals der Mathematische Co-Prozessor. Also warum soll es bei den APUs denn jetzt auf einmal anders ablaufen?

Erklär mir dochmal, warum ich mir dafür den Deckel aufsetzen lassen soll? Nur weil ich den Umstand anspreche? Und so nicht gut heißen kann? Sorry, aber was soll das?

Es ist jedem Bewusst, das es entsprechende Software braucht, du reitest nur andauern darauf herum. Im Prinzip verlangst du etwas von den APUs, dass es vorher noch nie gegeben hat, die Nutzung neuer Technik mit altem, schon compiliertem Code.

Was ich erwarte, ist doch völlig nebensächlich...
Mir ist das doch vollkommen egal, wer da auf dem CPU Deckel steht. Ich kaufe nach P/L. Und "L" definiert die Software die ich habe bzw. zu Benutzen gedenke. Also richtet sich die Kaufentscheidung einzig daran...

Und zum anderen, das ist auch schön so... Nur was macht dieses Wissen für einen Unterschied? Ohne Software, nix mehr Performance... Das Endresultat stand heute hat sich dahingehend nicht geändert. Oder steh ich auf dem Schlauch!?

Ich denke schon, dass es wichtig ist, was du erwartest, sonst würdest du nicht immer auf der fehlenden Software rum reiten ;)

Es muss ja keine Perfekte Lösung sein ;)
Sprungvorhersagen beispielsweise gibts nicht erst seit heute... Und die laufen eben auchmal ins leere. Aber es gibt sie und ohne sie wäre der Speed wohl auch deutlich? schlechter als mit.

Du vergleichst Äpfel mit Birnen. Eine Sprungvorhersage muss nur nach ein paar speziellen Befehlen filtern. Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.

Im Endstadium von Fusion sollte das aber auch weniger eine Rolle spielen. Nämlich wenn ALUs beispielsweise der CPU so beiseite gestellt werden, das beispielsweise jegliche Gleitkommaoperationen auf diesen ablaufen.
Eventuell löst man sich so auch irgendwann vom klassischen "Core" CPU Konzept. So gibt es dann eben nicht mehr die klassichen CPU Cores oder auch CPU Module in CMT Bauweise, sondern es gibt nur noch Int Cores mit ner ganzen Latte von Gleitkommaprozessoren beispielsweise. Gepaart mit ner Einheit, die eben die Berechnungen in Hardware auf die ALUs verteilt...
Nur ist das alles Zukunftsmusik...

Ich würde sagen die GPUs sind zZ. noch zu langsam für einzelne FPU Berechnungen (geringer Takt) und zu simpel. Da müsste sich erst was tun bis sie die FPU ersetzten könnten. Ein Aufbohren würde aber so viel Fläche kosten, dass die schiere Masse verloren gehen würde. FPU und GPU rechnen zwar beide mit Gleitkomma zahlen, doch haben sie beide ihre Stärken und Schwächen. Wir werden also noch eine ganze Weile mit CPU, FPU und GPU leben müssen.

Heute bzw. Morgen sehen wir eine CPU mit zwei Modulen in Form von Steamroller Cores, der eine GPU auf GCN Basis beseite gestellt wird und zwischen welchen die Möglichkeit besteht auf einen gemeinsamen Speicherbereich zugreifen zu können. Mit Ausnahme der shared Memory Funktion bleibt die GPU aber GPU und der CPU Part eben CPU.
Und wie gesagt, mach mich bitte nicht dafür verantwortlich, ich kann da nix für :wink:

Wo mach ich dich denn dafür verantwortlich?

Nur mal so, in heutigen Prozessoren ist die FPU immer noch eine eigenständige Einheit, die neben den Integerkernen verbaut wird ;)
Man hat sie zwar immer weiter Integriert, mit einem gemeinsamen Decoder und eigenen Befehlssätzen, es ist aber immer noch eine eigenständige Einheit.
 
Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.

Die Abschnitte kann der Entwickler ja auch markieren, so dass eingangs immer nur eine Abfrage stattfindet, man muss nicht den komplizierten weg gehen alles vorher zu analysieren. Du setzt dich ja auch in den Zug nach München, weil das Fahrtziel dadrauf steht und analysierst nicht erst ob der da auch wirklich hinfährt. ;)
 
Ich sag doch nichts anderes, der Compiler soll spezielle Befehle (eigenen Befehlssatz) oder irgend welche Flags setzten, .... Was fsdonne aber will ist, dass die Hardware das selbst entscheiden kann egal wie das Programm compiliert wurde und da bin ich der Meinung, dass das nie passieren wird.
 
Zuletzt bearbeitet:
Da würde ich einfach mal die Entwicklung abwarten, "smarter" dürfte die Hardware mit der Zeit definitiv werden. Nur wie schnell das geht oder wie "smart" die werden, steh wohl in den Sternen. ;)
 
Da würde ich einfach mal die Entwicklung abwarten, "smarter" dürfte die Hardware mit der Zeit definitiv werden. Nur wie schnell das geht oder wie "smart" die werden, steh wohl in den Sternen. ;)

Anscheinend wird der Bedarf an smarten Lösungen nur gezielt gefordert z.B. bei Berechnung und Entschlüsselung von großen Daten, also eher in Produktion und Forschung des Profibereichs. Da AMDs Kaveri auf den Desktopmarkt zielt, wäre ich nicht zu optimistisch, dass sich demnächst ein großes Momentum entwickelt. Zumindest kenne ich im Konsumerbreich aus der näheren Umgebung niemanden, der sich dafür interessiert, dass irgendwelche Apps oder Softwarelösungen signifikant beschleunigt werden.
 
Schau dir doch mal die Geschichte der Hard/-Softwareentwicklung an. Es kam noch nie vor, dass ein Feature von der Software genutzt wurde, bevor es spezifiziert oder die Hardware da war. Ein sehr gutes Beispiel ist wohl die FPU bzw. damals der Mathematische Co-Prozessor. Also warum soll es bei den APUs denn jetzt auf einmal anders ablaufen?
Wie lange gibts GPGPU nun schon?
Ich denke, das dürfte gegen Mitte 2007 mit CUDA seitens NV losgegangen sein... AMD folgte etwas später mit Stream.
Und was ist jetzt mit der Software? Ich sehe neben ein paar wenigen dedizierten Spezialfällen nix. Keine Alltagssoftware nutzt die GPU. Bzw. wenn, dann macht es die Sache nicht dadurch zum "Renner" und es geht genau so auch ohne... (Browser mit GPU Beschleunigung)
Das ist der Punkt... Das es erst eine Hardware geben muss, um überhaupt die Software darauf zu entwickeln sollte logisch sein, wurde auch von mir nirgends angezweifelt. Nur es gibt eben die Hardware seit Generationen schon... Nur wird sie überwiegend nicht ausgenutzt (bis auf den CPU Teil)...

Der Unterschied zwischen unseren Meinungen scheint einzig daran zu hängen, das ich eben aufgrund der bisherigen Software auf Hardware Anpassungen und dem Ansprechverhalten stark bezweifle, das die ganze Sache für AMD aufgeht. Mit dem Bulldozer ist man auf die Nase gefallen und das Ding ist viel zu langsam im Schnitt gegen die Konkurenz -> so das man das Ding mit hohen Taktraten, hohen Spannungen und vor allem viel zu niedrigem Preis anbieten muss.
Das APU Konzept selbst ist nicht verkehrt. Nur als Zugpferd (da will doch AMD aktuell hin mit APUs only für Sockel FMx in Zukunft) sehe ich die notwendig zu meisternden Hürden von externen Firmen als viel zu hoch an, dass da am Ende für AMD das rauskommt, was sie eigentlich bräuchten -> nämlich endlich mal wieder ein Produkt, was am Markt richtig gut platziert ist und wo man auch mit den Preisen mal nicht im Keller agieren muss.

Es ist jedem Bewusst, das es entsprechende Software braucht, du reitest nur andauern darauf herum. Im Prinzip verlangst du etwas von den APUs, dass es vorher noch nie gegeben hat, die Nutzung neuer Technik mit altem, schon compiliertem Code.
Genau hier zum Beispiel machst du mich dafür verantwortlich... Ich reite nicht auf der Software rum, ich spreche den Umstand an, weil der immer wieder verdrängt wird.
Ein Ansprechen des Umstandes wäre absolut nicht notwendig, wenn es allseits bekannt wäre... Ist es aber scheinbar nicht. Man schaue sich die Kommentare hier und in anderen APU Threads an, speziell eben zum Thema Fusion und Co. -> da denken sich scheinbar einige, das die Hardware auf einmal rasend schnell wird ohne irgendwelches zutun.
Beispiel gefällig:
http://www.hardwareluxx.de/communit...g-sample-aufgetaucht-987618.html#post21380793
Aus dem Zitat ist zu entnehmen, das die APU nun Berechnungen auf dem GPU Part ausführen kann... Wird dediziert erwähnt und hervorgehoben? Warum? Ja scheinbar legt man da Wert drauf... Und ich sage daraufhin -> ja schön und gut, aber du brauchst du die Software, die es sogut wie gar nicht gibt. Und wie die Vergangenheit zeigt, die sich bestenfalls mäßig schleppend an soetwas anpasst. Siehe Llano Vergleich. CPU Seitig noch langsamer als die aktuellen APUs, und die GPU bekommt auch nach 2,5 Jahren fast keine Aufgaben zu tun.

Ich denke schon, dass es wichtig ist, was du erwartest, sonst würdest du nicht immer auf der fehlenden Software rum reiten ;)
Nochmal, ich reite nicht drauf rum... :wink:
Ein Ansprechen des Umstandes, der von anderen vergessen, verdrängt oder einfach durch unwissenheit nicht beachtet wurde ist kein "rum reiten".

Du vergleichst Äpfel mit Birnen. Eine Sprungvorhersage muss nur nach ein paar speziellen Befehlen filtern. Ob ein Codeabschnitt aber auf der GPU beschleunigt werden kann oder nicht, hängt nicht von einzelnen Befehlen, sondern von seinem Aufbau ab.
Es gibt immer Mittel und Wege sein Ziel zu erreichen...
Auch ist es nicht meine Aufgabe, die APUs zu entwerfen oder den Jungs bei AMD irgendwelche Tips zu geben... Zumal ich mir das wohl nichtmal selbst anmaßen würde, zu tun.
Die wissen schon was sie machen.
Heist also, wie sie diesen Umstand entgegenwirken (oder ob überhaupt) kann bestenfalls spekuliert werden.
Und wenn es eben in Hardware nicht geht, muss es halt in Software gelöst werden. Wie Mick sagte... Oder man fährt bei der Entwicklung gleich mehrgleisig und entwickelt gewisse Funktionen usw. speziell angepasst für die Hardware X oder Y
Oder lässt gar dem User am Ende die Wahl usw. usf.

Ich würde sagen die GPUs sind zZ. noch zu langsam für einzelne FPU Berechnungen (geringer Takt) und zu simpel. Da müsste sich erst was tun bis sie die FPU ersetzten könnten. Ein Aufbohren würde aber so viel Fläche kosten, dass die schiere Masse verloren gehen würde. FPU und GPU rechnen zwar beide mit Gleitkomma zahlen, doch haben sie beide ihre Stärken und Schwächen. Wir werden also noch eine ganze Weile mit CPU, FPU und GPU leben müssen.
deswegen schrieb ich von Zukunftsmusik...



Wo mach ich dich denn dafür verantwortlich?

Nur mal so, in heutigen Prozessoren ist die FPU immer noch eine eigenständige Einheit, die neben den Integerkernen verbaut wird ;)
Man hat sie zwar immer weiter Integriert, mit einem gemeinsamen Decoder und eigenen Befehlssätzen, es ist aber immer noch eine eigenständige Einheit.

zum ersten, siehe oben beispielsweise... Jedesmal wenn ich mich hier kritisch über eine Sache äußere, kommen scheinbar immer die selben Leute und meinen da irgendwas dran aussetzen zu müssen.
Es macht den Eindruck, als wäre ich dran schuld, weil ich den Umstand anspreche... :wink:
Sollte es so nicht gemeint gewesen sein, ist auch OK ;)

Zum anderen, ja, aber was spielt das zur Sache?
Ich spreche mit meiner Software üblicherweise Programmiert in irgend ner Hochsprache nicht direkt die FPU an.
Das muss ich aber stand heute mit der GPU machen. -> und das ändert sich mit Kaveri genau Null, auch nicht durch HSA und hUMA. Oder habe ich hier nen Denkfehler?
 
Das Problem liegt mMn eher bei den Entwicklern und deren "Trägheit". Ich selbst schreibe meine Programme seit knapp 2 Jahren wenn irgend möglich so, dass die GPU die Aufgaben bekommt (Aparapi, OpenCL und APP-SDK). Vorteil meinerseits ist einfach die Entwicklungszeit und der Entwicklungsaufwand (verhältnismäßig kleine Programme für explizite Kundenanforderungen).
Wenn man aber erst ne ganze Menge an fertigen Modulen hat, nutzt man, was man hat und fertig ist. Also bleibt es beim Berechnen über Standardcompiler und somit bei der CPU...
Das wird sich auch nicht wirklich ändern, außer ein Treiber oder ein Zusatzchip kümmert sich in naher Zukunft darum, in Echtzeit die Entscheidung dafür treffen zu können, was an die Graka gehen kann und was nicht bzw. kümmert sich um die entsprechende Vorbereitung des Codes.
Wäre ja schon ein riesiger Fortschritt, wenn die VMs/Laufzeitumgebungen der höheren Programmiersprachen nativ auf der Graka laufen würden...
 
fdsonne schrieb:
Zum anderen, ja, aber was spielt das zur Sache?
Ich spreche mit meiner Software üblicherweise Programmiert in irgend ner Hochsprache nicht direkt die FPU an.
Das muss ich aber stand heute mit der GPU machen. -> und das ändert sich mit Kaveri genau Null, auch nicht durch HSA und hUMA. Oder habe ich hier nen Denkfehler?
Deshalb versucht AMD ja die OpenCl Verbreitung zu steigern. z.B. LibreOffice: [Phoronix] LibreOffice Lands A Ton Of GPU OpenCL Functions. Hm kommt ein Monat zu spät. Ich hätte schon gerne gesehen, ab welcher Projektgröße das was bringt. Auch der Multicore Support ist interessant: [Phoronix] LibreOffice Getting Better Multi-Threaded Goodness
freut mich ich nutze LibreOffice.
Viel wichtiger sind die Kompiler:
Heterogeneous Queuing: AMD will CPU und GPU enger zusammenarbeiten lassen | heise online
Mal sehen ob alte Javaprogramme davon auch profitieren.
smoothwater schrieb:
Das wird sich auch nicht wirklich ändern, außer ein Treiber oder ein Zusatzchip kümmert sich in naher Zukunft darum, in Echtzeit die Entscheidung dafür treffen zu können, was an die Graka gehen kann und was nicht bzw. kümmert sich um die entsprechende Vorbereitung des Codes.
Meiner Meinung würde es ausreichen wenn der Kompiler das übernimmt. Ich stell mir das einfach in Echtzeit nicht so performant vor, wobei das in Java oder einer anderen Programmiersprache, deren Kompilat nicht direkt auf der Hardware ausgeführt wird, wahrscheinlich ginge.
Schön wäre es wenn gcc oder ein anderer Open-Source Kompiler dies könnte. Dann dauert das Kompilieren zwar länger, aber man müsste die Entscheidung nicht in Echtzeit treffen.
 
Wenn das Programm direkt an dem System erstellt wird, wo es letztlich ausgeführt wird, stimme ich dem zu. Ansonsten sind wieder zuviele Hardwareabhängigkeiten drin, die bei der Code-Erstellung beachtet werden müssten (oder aber es wird direkt in OpenCL gewandelt, weil das alle Großen unterstützen). Java geht ja schon in die Richtung (Java 9 / Aparapi).
 
Deshalb versucht AMD ja die OpenCl Verbreitung zu steigern.

Und das ist genau das was ich oben sagte... Man versucht den Markt dort hin zu entwickeln, wo es einem selbst am besten nutzt.
Unterm Strich natürlich nicht primär ein Problem. Aber AMD ist leider der kleinere der beiden. Und hat auch entsprechend weniger Marktmacht für solche Spielereien.

Das ganze stelle ich mir im OpenSource Bereich sogar noch ganz praktikabel vor. Für so einige Projekte mit halbwegs anständiger Marktdurchdringung gibts ja heute schon teils angepasste Versionen, bzw. wenigstens spezielle "Kompilate" für die verschiedenen Hardwareansatze (auch im x86 Bereich)
Nur fehlt das aus meiner Sicht quasi vollständig in der kompletten Windows und OSX Welt... Letztere baut halt native auf Intel mittlerweile, also nicht verwunderlich. Aber die Windows/Linux Welt jenseits von irgendwelchen kleineren OpenSource Projekten scheint davon wenig bis nix wissen zu wollen... :wink:
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh